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Abstract 

This document summarizes the progress we have made on our 
study of issues concerning the schedulability of real-time systems. 

Our study has produced several results in the scalability issues of dis- 
tributed real-time systems. In particular, we have used our techniques 
to resolve schedulability issues in distributed systems with end-to-end 
requirements. During the next year (1997-98), we propose to extend 
the current work to address the modeling and workload characteriza- 
tion issues in distributed real-time systems. In particular, we propose 
to investigate the effect of different workload models and component 
models on the design and the subsequent performance of distributed 
real-time systems. 

1 Introduction 

The stringent demands to guarantee task deadlines in real-time sys- 
tems have motivated both practitioners and researchers to look ways 
to analyze systems prior to run-time. In our study, a new perspec- 
tive of analyzing real-time systems that can guarantee meeting the 
deadline guarantees as well as qualify the guarantees. We express 
the qualification of the deadline guarantees through a scaling factor. 

In simple terms, the scalability factor enables one to decide by how 
much the execution time of each of the subtasks in a distributed task 
be increased still retaining the deadline meeting guarantees. 
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In this work, we have solved several scheduling problems using the 
scalability factor. Following is a summary of the results. The details 
of the work are in the appendix [1, 2, 3]. 


2 Summary of Work done during 1996- 
97 


The results from our work on scalability based admission control [3] 
can be summarized as follows: 

• Two heuristics were developed using scalability factor. Heuristic 
1, referred to as R, uses non-optimal low-cost computation of the 
scalability factors. Heuristic 2, referred to as S, uses an optimal 
computation of the scalability factors. 

• For low utilizations, we observe that both heuristics have similar 
admissibility. Given that R is less expensive than S, we recom- 
mend that the former be used under low utilizations. 

• For a given value of number of channels amd a given tightness 
of the deadlines, we observe that the admissibility of R falls 
abruptly beyond a certain utilization factor. So R should be 
used only when the utilization is lower than this bound. 

• The performance of 5, however, degrades gracefully beyond the 
utilization bound. Hence, this has a better resilience to utiliza- 
tion that R. 

• As the number of channels increases, the success of heuristic 5 
improves compared to R. 

• S has better performance with respect to rejecting inadmissible 
channels compared to R. Thus S is to be preferred when the cost 
of accepting inadmissible channels is high. 

The results from our work on scalability in real-time systems with 
end-to-end requirements [1] has the following conclusions: 

• We have identified several issues of concern that researchers and 
practitioners face during the design, development, and mainte- 
nance of complex real-time systems. 
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• We have shown that the questions posed by these issues can be 
formulated from two viewpoints: component changes and task 
changes. 

• We reduced the above two problems to two fundamental prob- 
lems, viz., a schedulability of a task-set with arrival times and 
its scalability. 

• We have presented optimal solutions to the two problems. 

The PhD thesis [2] summarizes much of the work done during the 
last four years. It illustrates in a great detail the results obtained 
in scalability of uniprocessor systems, schedulability of task-sets with 
specified arrival times, and the scalability in distributed systems with 
end-to-end deadlines. The techniques developed have been illustrated 
by taking data from Olympus Attitude and Orbital Control System. 
The significant contributions of the thesis axe summarized as follows. 

• We have addressed the need to handle complexity in real-time 
systems in all phases, viz,, design, development, and mainte- 
nance. 

• We have presented a novel perspective to analyzing real-time 
systems that in addition to ascertaining the ability of a system 
to meet task deadlines also qualifies these guarantees. 

• The need to qualify guarantees was shown to arise from several 
scenarios such as scaling application requirements, inaccuracies 
in task execution time estimations, and porting applications from 
one platform to another. 

• We presented an application of the scaling factor problem in the 
context of real-time communications. We considered the problem 
of admission control of real-time channels. 

3 Proposed Work During 1997-98 

In the 1997-98 period, for which we are now seeking funding, we pro- 
pose to extend our current research on the following issues. 

L How does component modeling effect the end-to-end scheduling 
in distributed real-time systems? In particular, we wish to look 
at the micro elements such as the memory/cache modeling and 
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the macro elements such as the networks. As a result of this 
work, we should have a better understanding of the impact of 
modeling on the design of these systems. Does complex models 
mean better designs? 

2. How does traffic characterization impact the design and analysis 
of distributed real-time systems? This issue has close relation- 
ship with the component modeling discussed above. For exam- 
ple, if we are considering the memory/cache system, what are 
different traffic characterizations of the incoming reference pat- 
tern? Does this characterization greatly affect the design and 
analysis where it is often used? Once again, we expect to de- 
velop several traffic models at different components (or sources) 
in a distributed system. We shall evaluate their suitability in 
different applications. 

3. Since jitter in response time is of particular concern to several 
real-time applications such as multimedia and control applica- 
tions, how accurately can the end-to-end jitter be predicted or 
controlled? We are especially interested in using this informa- 
tion at the design stage. This step will use the results from the 
earlier two steps. 
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Abstract 

The stringent demands to guarantee task deadlines in real-time systems have motivated both practitioners and researchers 
to look at ways to analyze systems prior to run-time. This paper reports a new perspective of analyzing real-time systems 
that in addition to ascertaining the ability of a system to meet task deadlines also qualifies these guarantees. The guarantees 
arc qualified by a measure (called the scaling factor) of the system’s ability to continue to provide these guarantees under 
possible changes to the tasks. This measure is shown to have many applications in the design (task execution time 
estimation), development (portability and fault tolerance) and maintenance (scalability) of real-time systems. The derivation 
of this measure in end-to-end systems requires that we solve two fundamental problems - the uni-processor schedulability 
problem and the uni-processor scalability problem. The uni-processor schedulability problem involves finding whether a set 
of tasks (with arbitrary non-zero arrival times) will meet its deadlines. The scalability problem seeks to find the maximum 
scaling factor with which the execution times of a set of tasks can be scaled without invalidating its schedulability. Optimal 
solutions to these two fundamental problems are presented. 

Keywords : Real-time systems; Schedulability; Scalability; End-to-end; Distributed systems 


1. Introduction 

A real-time system can be characterized by two 
important components: the environment in which the 
system is operating and the computer system that 
controls/monitors the environment. The main issues 
in the design of the first component concern interfac- 


" Corresponding author. Email: ramesh@abacus.mwsu.edu 
1 This work is sponsored by a grant from NASA (NAG-l-1 1 14). 


ing with the environment [11]. Solutions in this area 
are primarily dictated by the technology. There are 
many issues of concern in the design of the second 
component, the computer system. The computer sys- 
tem involves both the hardware and the software that 
runs on them. The choice of hardware is dictated 
primarily by such parameters as cost/availability 
and the application at hand. The primary issue in the 
software design is not so much, the particular choice 
of language or programming paradigm as it is the 
way the various tasks are scheduled. 


1 383-762 I/O 1 65-6074/96/Sl 5.00 Copyright © 1996 Elsevier Science B.V. All rights reserved 
Pit S 1383-7621(96)00031-8 
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are based on the critical instant argument, which 
defines a worst-case condition for a task. According 
to this argument, a task suffers its worst completion 
time when it has to compete for the processor with 
every higher priority task in the system. That is, 
when it arrives at a time when all other higher 
priority tasks also arrive. This instant is called the 
critical instant. Accordingly, it is sufficient to look at 
the completion time of this one instance in order to 
ascertain the tasks schedulability. But does this com- 
putation really give us the worst-case completion 
time of a task? In other words given a task’s charac- 
teristics, will it ever suffer this completion in reality? 
Notice that the critical instant argument clearly ig- 
nores the arrival information of tasks and makes the 
assumption that for a given arrival (relative to other 
tasks) of a task, sooner or later (one of its instances) 
it will meet a critical instant. It can be seen however 
that, this is not necessarily true and the actual worst- 
case completion time of a task can be less than or 
equal to the completion time computed by the criti- 
cal instant assumption. Therefore, ignoring the ar- 
rival times of tasks and using the critical instant 
argument leads to a pessimistic computation. 

Can we tolerate the pessimism inherent to this 
computation? The answer to this question depends 
on the environment under consideration, viz., a uni- 
processor or a distributed (more generally end-to-end) 
system. In uni-processor systems, depending on the 
assumptions (task independence for example) made, 
practitioners [10] have argued that the cost of finding 
a more precise measure of the task completion time 
far outweighs the benefit gained (say, in terms of 
saved resource utilization). However, there are con- 
vincing arguments to the contrary by Tindell in [7]. 
He discusses scenarios that show the importance of 
considering the task arrival information in schedula- 
bility analysis. We believe that the importance can 
be really felt in end-to-end systems and not so much 
in uni-processor systems. 

Recall from the previous section that the schedu- 
lability of a task in an end-to-end system can be 


reduced to a sequence of uni processor schedulabil- 
ity problems provided we are able to compute the 
characteristics (period and arrival time) of the sub- 
tasks. Let us assume for now that we have a mecha- 
nism to compute the sub-task periodicities (the 
mechanism will be described in detail later). We do 
not require the arrival time information by the criti- 
cal instant argument, since we are going to ignore it 
anyway. We can use the critical instant argument 
(ignoring the arrival time a ik ) to find the worst case 
completion times of all sub-tasks T ik (1 ^ k <> m). 
Clearly, the worst case completion time of the task T i 
is given by the sum of the worst-case completion 
times computed above. Observe that we have a 
cumulative measure of pessimistic computations that 
is bound to be more pessimistic. 

Before we give a description of the problem we 
are interested in addressing in this paper, we would 
like to motivate the reader by briefly discussing the 
source of the problem. In the previous section we 
mentioned that the kinds of changes (that interest us) 
that systems undergo manifest themselves as task 
execution time changes. A brief discussion of these 
changes follows. 

The task parameters, deadline and periodicity are 
dictated primarily by the environment. The arrival 
time of a task is governed by the environment and 
the inter-dependence between the tasks. The execu- 
tion time of a task on the other hand is governed 
among other things by: (l) the programming lan- 
guage chosen, (2) the compiler, (3) the operating 
system, and (4) the processor architecture (e.g., 
pipeline, cache). Therefore, finding the execution 
times of tasks is complex and involved. In most 
cases it is almost impossible to compute a determin- 
istic measure of the execution time of a task. Most 
research efforts use the worst-case task execution 
time and not the mean execution time. While this 
choice can be justified by the fact that the analysis is 
based on the worst-case scenario, it nevertheless 
results in an over-design of the system. Also, this 
assumption can result in poor resource utilization. 
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• Arrival time of the task, a r 

• The periodicity of the task, p t . 

• The deadline of the task, The deadline is 
assumed to be less than or equal to the period 
( d i ^ p,X In other words, an instance of a task has 
to be completed before its next instance is ready. 

• The execution times of the m sub-tasks (corre- 
sponding to the m components in the system), 

T ii* T n T im : *,i>*i 2 * •••.*/«,- In this model we 

assume that a component is used only once by a 
sub-task; relaxing this assumption complicates the 
model without adding any quality to the results 
that can be derived. If any task 7} does not have a 
sub-task on a particular component R k then, the 
corresponding sub-task’s ( T jk ) execution time e Jkt 
is zero. 

• Priority of task, Pr { . We assume that all sub-tasks 
belonging to a task inherit the tasks priority. This 
assumption can be easily relaxed without affect- 
ing the results reported in this paper. For conve- 
nience in representation, we assume that the tasks 
are ordered (indexed) according to their priority, 
i.e., 7, is the highest priority task and the priority 
decreases with the index. 

The above notation can also be used to capture a 
task-set in a single component system, for example, 
the uni-processor system. If we restrict the number 
of components, m to be 1 , we have each end-to-end 
task T { comprising of a single sub-task 7),. Further 
the other parameters, arrival time, period and dead- 
line of the task are also those of the sub-task. In such 
a scenario we drop the subscript describing the com- 
ponent. 


4. Problem statement and description 

The problem we are interested in solving is the 
“Scalability of task-sets in end-to-end real-time sys- 
tems”. The problem can be looked at from two 
different viewpoints: (1) The first viewpoint stems 


from assuming the scaling to occur as a result of a 
change in one or more of the components in the 
system; and (2) the second viewpoint stems from 
assuming the scaling to occur as a result of a change 
in the functionality of some or all of the sub-tasks in 
the system. 

4A. Component change 

A change in a component R r can result in a gain 
(no adverse affect on schedulability) or a loss (ad- 
versely affects schedulability) in the speed of pro- 
cessing for the sub-tasks running on it. The problem 
of interest therefore is, to find the maximum factor 
by which all the sub-tasks on a particular component 
R r can be scaled such that the schedulability of the 
task-set (comprising all n tasks that is) is unaffected. 

In the following formulation we assume that a 
single component is undergoing a change. We can 
however, generalize it to a sub-set of components. 
The problem of scaling occurring as a result of a 
component change can now be formally posed as: 

Problem 1. Given a task-set T of n end-to-end tasks 
executing in a system of m, (m£ 1), components, 
find the optimal scaling factor 1 /sfc (corresponding 
to a maximum sfc) with which the processing speed 
of a given component r can be scaled (down), 
without affecting the schedulability of the task-set. 

In other words, we are interested in the maximal 
component change the taskset can survive. The rea- 
son for representing the scaling factor as a reciprocal 
is obvious once we realize that a lowering in pro- 
cessing speed of a component will reflect as an 
increase in the execution times of sub-tasks running 
on the component. For example, if the speed of the 
component is S (instructions per unit time) then an 
execution time requirement of a sub-task T lk being 
e ik (time units) implies that the number of instruc- 
tions that the sub-task requires to execute are 5 X e ik . 
If the processing speed is scaled down by 1 /sfc 
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• The periodicity of all sub-tasks T Jk , (j ^ t), which 

are of higher priority than T ik and are running on 

the same component R k . 

Therefore, we need a mechanism by which we 
can derive these two parameters (since these are not 
given a priori). Note that, only the first sub-task of 
any task is truly periodic. The arrivals of the consec- 
utive instances of any sub-task T ik , (1 ^ i £ n\ 1 < k 
£ m), are dictated by the completion times of the 
sub-task preceding it, i.e., T i k __ , . These completions 
are obviously non-periodic and so are the arrivals of 
sub-task T ik . We however can impose a periodicity 
on these sub-tasks by a proper justification. The 
phase adjustment mechanism [3], is one such mecha- 
nism that derives sub-task arrival times and also their 
periodicities. The term phase here is used to denote 
arrival time. 

Imposing a period on the arrivals (of consecutive 
instances that is) of a sub-task T ik> (1 <k<*m\ 
implies that, even if the preceding sub-task T ik ^ } 
does finish at a particular time 4 (say F ( *_,), the 
sub-task T ik will not be ready immediately. A finite 
amount of time (say -F iJfc _,) has to elapse 

before the sub-task T ik is ready to execute. It is 
necessary to limit this finite amount of wait time in 
the sense that, if it is too large then it could hurt the 
utilization of the component R k . On the other hand 
this delay must be large enough to be able to accom- 
modate all possible finish times (of its various in- 
stances) of task T ik _ , . Clearly, therefore, in the 
limiting condition (delay = 0) W i k _ , must be given 
by the worst-case completion time of the sub-task 

T itk - 1. 

An effect of this adjustment is that a sub-task T ik 
will always be ready (or arrive) after a constant 
amount of time from the arrival of the preceding 


4 All references to time are relative to / =* 0, unless otherwise 
specified. 


sub-task 7) a _,. Therefore, knowing the arrival time 
of the sub-task 7^, we can find the arrival of the 
sub-task 7 /2 , knowing which we can find the arrival 
of T iy and so on. It should be clear to the reader that 
the above adjustment allows all sub-tasks belonging 
to a task to inherit its period. 

What the above adjustment has afforded us is, the 
ability to treat each of the components indepen- 
dently, provided we are able to find the worst-case 
completion times W ik (V/,&). Observe that we have 
all the information about sub-tasks T i{ (1 ^ i <> n), 
running on the first component, R { (that is, we have 
their arrival times, periods and execution times). 
Now the problem we wish to solve is finding the 
worst-case completion times of these tasks. Once we 
find these worst-case completion times we have all 
the information about sub-tasks 7. 2 , (1 ^ i ^ «), run- 
ning on the second component, R 2 and so on. The 
problem can be formally posed as: 

Problem 4. Given a task-set T of n tasks executing 
on a single component, find the woist-case comple- 
tion times of all tasks in the task-set. 

Now that we have a mechanism to test whether a 
given task-set is schedulable, we have answered the 
question of whether there exists a scaling factor as 
defined by the two problems. Problem 1 and Prob- 
lem 2. Clearly, if the tasks are so stringent that any 
increase in the execution times of the sub-tasks 
cannot be tolerated, then the scaling factors sfc (as 
defined in Problem 1) and sft (as defined in Problem 
2) will both be equal to 1.0. 

The end-to-end schedulability problem has been 
reduced to m single component worst-case comple- 
tion time computation problems and not m single 
component schedulability problems. Therefore, we 
cannot talk about extending a single component’s 
schedulability, unless we derive the sub-task dead- 
lines. A major research issue in end-to-end schedul- 
ing has been the derivation of sub-task deadlines. 
Given an end-to-end task’s deadline the problem of 
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arrivals), we can derive an alternate phasing A' 
which has the characteristic that the arrival times 
monotonically increase with the priority. 

The following theorem is the basis for the ap- 
proach. 

Theorem 1. Given that the arrival times of tasks in a 
task set are inverse monotonic with priority , the 
worst-case response time instance of a task T i be- 
longs to the interval [a i ,a i + LCM(T lt . . . ,7))]. 

Proof, For task, T it the only tasks that it would have 
to compete with, are the higher priority tasks 

7,,7 2 7). We are therefore interested in finding 

that point in time at which, the phasing of task T i 
(given by a { + jr, X p { , for the x r th instance) with 
respect to other higher priority tasks is same as that 
at time a,. Further, this point must be such that the 
state of the scheduler must be same as it was at a r 
The relative phasing of task T t with respect to the 


task 7, can be captured as: Task comes a i - a { 
units of time after task 7,. Assuming the existence of 
a point where this phasing repeats, and further that 
there are x, and x t instances respectively of 7, and 
Tj before this point, we have the following condi- 
tion: 

(a, +x,.Xp l ) ~(a, + *, Xp,) = a, -<!,=» X Pl 

= x i Xp l . 

We can derive similar conditions for task T { other 
tasks. The resultant condition is: 

X\ Xp| = x 2 Xp 2 = ... =X;Xp, = L, 

where a { + L is the desired point. Clearly the LCM 
of pj is the solution for the above equation if we 
assume integral values of p { . 

Next, we have to show that the state of the 
scheduler with respect to the task T i is the same at 
both points a, and a i + L. We use the method of 
mathematical induction to show this. 
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Fig. 1. A task-set’s execution between the start and L. 
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Algorithm 1 

Arb_to_Iner 
Begin( Algorithm) 

Input : A = {a,,tf 2 a n }, and p,,p 2 p n 

Result : A' = {d {J d 2 , . . . ,d n ] 

/mV: A' = A; 

77ie /irsf task arrival is unchanged, 
for (i = 2 ro n) do 
if (a i <o'_ l ) 

y=l\ 

while (a, + y X p : < |) do 

y = y+ i\ 

enddo 

d-, = a, + y X p,\ 

endif 

enddo 
return A'; 

End{ Algorithm}. 

We take an example (refer to Fig. 2) to demon- 
strate the operation of the above algorithm. Consider 
a task-set with four tasks (r,,r 2 ,r 3 ,r 4 ), with the 
following values for arrival times and periodicities: 
(a, = 5 ,a 2 - 3 ,a 3 « 4 ,a 4 - 0), (p, = 10, p 2 = 10, p 3 
« 16,p 4 =» 12). The first task’s arrival time remains 
unchanged, however since the task Tf s arrival is 
before 7,’s, its new arrival time, d 2 , is computed to 
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Fig. 2. Conversion of arbitrary 
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increasing 
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Example. 


be a 2 + p 2 which is 13. Now task 7 3 ’s arrival time 
a y = 4 is less than d 2 — 13, therefore its new arrival 
time af s is a l -fp s which is 20. Task T 4 arrives at 
a 4 — 0 which is less than d } = 20, therefore its new 
arrival time d 4 is a 4 + 2 X p 4 which is 24. Now the 
new arrival times of the tasks in the task set are 
(o', = 5 y d 2 = 13,^ = 20 ,d 4 = 24). 

Before we discuss the mechanism in detail, it is 
important to ascertain the relationship between the 
original arrival pleasing and the modified arrival 
phasing. Since the modified arrival pattern guaran- 
tees the repetition of the task-set behavior, in order 
to find the worst-case response time of any task, we 
only have to look for its instances between its origi- 
nal arrival time and the point at which the new 
phasing repeats itself. The algorithm for the com- 
plete mechanism follows: 

Algorithm 2 

Begin{ Algorithm } 

Input : A = (a^a 2 a n ) y <*nd p ,,/ p„ 

Find the modified arrival times , A', for tasks by 
invoking the procedure Arb_to__Incr; 
repeat for each task T i in turn: 

Find the completion times of all task instances 
of T i occurring in the interval a,, and d i + 
LCM{T Jf j<Zi); 

Find the maximum and report it as the worst- 
ease completion time of the task 7); 

Compare the worst-case completion time 
against the deadline to see if T t meets its 
deadline ; 

End{ Algorithm) 

We now consider an example (Table 1) task-set to 
demonstrate the need for accommodating task ar- 
rivals as opposed to adapting the critical instant 
argument. In Table 1, the last two columns give 
respectively the worst-case response times of the 
tasks using the critical instant assumption (W c ) and 
our approach (W r ). It is clear that the critical instant 
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In the following, we give an algorithm to find the 
optimal scaling factor when an arbitrary (RMS and 
DMS being two instances) fixed priority assignment 
is used. Before the details of the mechanism are 
presented we would like to intuitively motivate the 
idea behind it. We consider the case of scaling all 
tasks (as opposed to a sub-set) to present the motiva- 
tion. One approach would be to consider a succes- 
sive approximation technique as taken by [10]. Incre- 
mental factors are used to scale tasks and perform a 
schedulability analysis to confirm if the increment is 
acceptable. Clearly, such a technique would be ex- 
pensive. 

An alternative approach would be to incorporate 
the scaling factor computation into the schedulability 
test. This is the approach we have taken. The schedu- 
lability test we use is the one proposed by Lehoczky 
in [15]. The idea behind Lehoczky’s schedulability 
test is to ascertain the schedulability of each task in 
turn starting from the highest priority task. The 
schedulability of each task involves considering all 
tasks that are of higher priority than itself. Therefore, 
the schedulability test of a task can be interpreted 
as follows: To ascertain whether task T { will meet its 
deadline while continuing to honor the timing re- 
quirements of all higher priority tasks. Note that the 
test does not consider whether the higher priority 
task meets its deadline. It only makes sure that any 


higher priority task will not wait for the processor 
while a lower priority task is using it. In other words, 
it ensures that in every p j ( j < i) time units the task 
corresponding task T j would get €j units of the 
processor’s time. It is possible for example that a 
higher priority task 7} gets its last unit of required 
execution time between dj and p J (note dj^pf 
\ <>j <> n), thus meeting its demand but not its dead- 
line. 

On the same lines our approach to finding the 
scaling factor attempts to find the scaling factor for 
each task in turn starting from the highest priority 
task. The scaling factor (sf l ) obtained with respect 
to a task T i therefore guarantees that the task T ( 
would meet its deadline continuing to honor the 
scaled (scaled by sf ') requirements of all higher 
priority tasks. In other words, sf* is the factor with 
which the execution times of all tasks with priority 
greater than T { and including T i can be scaled with- 
out T f missing its deadline even after accommodat- 
ing all the scaled higher priority tasks. The required 
scaling is then the minimum of all computed scaling 
factors sf. A more detailed treatment of the solution 
follows. 

In the discussion above, we assumed that T= S in 
order to simplify the explanation of the solution. In 
this context we gave a definition of sf* that needs a 
slight refinement to adapt to the case that the set 5 is 



U IL y U|R U2L U2R U3L U3R UkL U t R 

t * , 


Worst-case phasing for Tj 
(critical instant ) 


■ Marked | — | _ Unmarked 

"Used Time I — I "Used Time 


Fig. 3. Task 7,’s execution profile. 
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S is assumed to be sorted in the increasing order 
of their priorities . 

Assume that T h is the highest priority task in the 
subset S. 

Step 1: for (i =* A; / ^ n\ i + + ) do 

Step 1.1: Compute first approximation for the 
completion time of task T f ' s first job: 
comply = Lj. , 10 i e j 

Step 1.2: Calculate the next approximation for 
completion time: comply , — e t + 

\ compl,/ Pj ]e. 

Step 1 J: if (comply , > d) 

then The job missed its deadline: Exiti— })\ 
Step 1.4: if (comply , # compl t ) 

then we have not arrived at the completion 
time of the task „ so, goto Step 1.2 ; 

Step 1.5: The completion time for the job is 
comply 

Step 1.6 : Fit higher priority task instances that 
would arrive between the points compl t and d r 
The scheduling points are U 2L ,U yLf . . . t U kL , 
where , U m — U mR — U mL , denotes the m-th used 
time block ( refer to Fig. 3). 

Further we identify each used block as a sequence 
of marked and unmarked sub-blocks where a 
sub-block of block U m is marked ( referred to as 
if it is the j-th marked sub-block of U m ) if it 
belongs to the sub-set S and if its priority is 
greater than that of task T). Unmarked otherwise 


Step 1.7: Compute the maximum possible scab 

ing factor sf : sf 1 = max , s s k . , sf m 

where 

enddo 

Step 2: sf — Minimum (sf) V/ 

Step 3: sf is the required optimal factor. 

End{ Algorithm) . 

1. Scaling in a single component system: With 
arrivals 

The following section describes a mechanism for 
finding the scaling factor that incorporates the ar- 
rivals of tasks. In order to simplify the presentation 
we assume that the scaling factor we desire is a 
common scaling factor for all tasks in the task-set. 
The case of general scaling (sub-set scaling) can be 
easily derived on the same lines. As we did when we 
dealt with the problem of schedulability using arbi- 
trary task arrivals in Section 5 t we assume that the 
arrival times of tasks are in increasing order of their 
priorities. The important difference between the 
treatment here and in the previous section, comes 
from the fact that when we are finding the scaling 
factor with respect to a particular task T it we no 



Fig. 4. Execution profile task T- s first instance. 
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W XL “ + ^|X * l * s possible that the 

resultant factor does not scale U { to occupy the 
whole of the idle time between (£/, *,t/ 2 L ), result- 
ing in U 2 being stretched beyond f/ 3 L and conse- 
quently the completion time being stretched be- 
yond U} L (we call this the unfavorable event for 
this choice of scaling factor NFE2). Note that this 
possibility has come up because the task 7} is not 
ready to use the idle time between (t/ t Ry U 2L ). 
On the contrary, in the event that this factor 
causes £/, to be scaled beyond the point U 2L (we 
call this the favorable event for this choice of 
scaling factor, FE2) then clearly the completion 
time of task T i will be within (/ 3 L (in fact it will 
be exactly U XL ). 

We note that there are two possibilities (or events) 
in favor of each of the above choices and two that 
are not in favor. However, we will show that the true 
answer lies in finding the minimum of these two 
possible factors. That is, picking the minimum of 
these two factors as the solution leads us to realize 
that the unfavorable possibility is actually not possi- 
ble. An explanation follows. 

We have two possibilities to consider 

• f<f: The favorable event (FEl) corresponding 
to this choice of the factor is valid in giving us 
the desired result. However, we have to show that 
unfavorable event, NFE1 will not occur. We show 
this by contradiction: Let us say (/, gets scaled 
beyond the point U 2L (i.e., the event NFE1 does 
occur). f 9 being the larger of the two, using it as 
the scaling factor would scale £/, beyond U 2L 
too. But, since f has been derived to stretch both 
U x and U 2 over (0 ,U XL ) t if it does stretch into 
the start of U 2f then there would be no idle time 
between the points (0,f/ 3 L ). This implies that 
f < f because, the bumped time 7 , say 5 ( =/ X 


U\ - U 2L ) and the scaled U 2 ( = /' X U 2 - U 2 ) 
together fitted within the interval between 
(C/ 2f *,£/ 2 ^X whereas / scaled only U 2 to occupy 
the same interval. The conclusion that, f < f 
contradicts our assumption that / is the smaller of 
the two factors. Hence the result. 

• />/*: The favorable event (FE2) corresponding 
to this choice of the factor is valid in giving us 
the desired result. However, we have to show that 
unfavorable event, NFE2 will not occur. We show 
this by contradiction: Let us say C/, does not get 
scaled beyond the point U 2 L when scaled by f 
(i.e., the event NFE2 does occur). Since, /> /', 
U 2 does not go beyond f/ 3 L when scaled by /'. 
However, the very definition of NFE2 says that / 
stretches U2 beyond U XL . This is a contradiction. 
Hence the result. 


Observe that the favorable events in both choices 
of scaling factors achieve the following: The comple- 
tion time of the task 7] is stretched in the point f/ 3 L . 
We now extend this to the case that the number of 
blocks of execution prior to the arrival of the first 
instance task T i is more than one. In fact, we wish to 
extend this argument to the case that there are q — 1 
blocks of execution before the arrival of the first 
instance of T r The generalization is straightforward. 
If there is more than one block of execution then the 
scenario would be as in Fig. 4. The scaling factor 
associated with stretching the completion time of the 
first instance of task 7, to consume the first idle 
interval beyond its completion would be given by: 


F n - Min 


E u r 

r- l to q 


U,+ l.L-U7.L 

E u r 


7 The excess scaled time that was carried from scaling £/, 
beyond the point (J 2 L . 




q.L 


u r 
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where q is the index of the block that contains the 
arrival of the first instance of T i . We represent this 
factor by F q to signify that this is the factor with 
which all tasks 7 ; (y «= i) must be scaled to fill the 
first idle interval after the completion (known to 
overlap with the block U q ) of this instance of task T r 
The subscript q here is only to identify the block 
which overlaps with the completion of this instance 
of T r The representation will become clear when we 
proceed to the next stage of derivation, i.e., the 
scaling factor for an arbitrary instance of 7- (not just 
the first that is). 

Now consider the point corresponding to the 
deadline of this instance of 7]-, a i + d r Our aim is to 
try to extend the completion of this instance at most 
till this point. Clearly, if this point overlaps with a 
used block (call it , £ ), then we cannot possibly 
extend 7/* s completion beyond the start of this 
interval. This is obvious from the fact that the over- 
lapped block in question contains executions of 
higher priority tasks that cannot be preempted by T ( . 
On the other hand, if the point in question does not 
overlap with any used block then we can consider 
filling only part of the idle interval that contains this 
point, viz., the idle interval between the right end of 
the used-block preceding the deadline point and the 
deadline point itself. In this second case, we set 
U k + ltL = a f 4* d i = U k + j i.e., we create a zero sized 
used block that overlaps with the deadline. Here k is 
the index of the used-block that precedes the dead- 
line. 


Therefore, if we assume that there are k - q such 
idle intervals beyond U q and before the deadline of 
this instance at d) then we have to find k - q such 
scaling factors F m (that is q <> m <, k). Now, the 
general formula for F m is given by: 


F m = Min 


Um+\.L Ul.L Um+\.L ^2 ,L 

E Ur E U, 


u m+ ,. t - u q _ L 
E u r ’ 

r» a in m ' 


The scaling factor for the first-instance of T t is 
the maximum among all computed factors for ac- 
commodating the idle intervals beyond the instance’s 
completion and before its deadline. Therefore, the 
required factor is: 

sf“= Max F m . 

qZm£k 

We now have to generalize the above formula for 
any arbitrary instance of T i (say the /-th). Clearly 
there are x i (refer to Section 5) instances of T i that 
have to be considered. Therefore, i ranges from 1 to 
x r If we find the scaling factors sf il for each of the 
jCj instances of 7% then we can obtain the scaling 
factor sf i as the minimum among all these. This is 
clear from the fact that picking a factor larger than 


Completion of 1'th instance of task Ti = dj * U|t + j ji 

s 

mm m 

; Uv t | Uvi j 

■31 ssm ■ • ■ El 

^ i 

Uy.L t/ v ,RUv+l,L Jt Uc 

aj + (1- 

L tiq,R Uq + lX t/kX Uui 

)*pi= Arrival of 1’th instance of task Tj [^| = Used Time 


Fig. 6. Execution Profile of the /-th instance of T r 
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the minimum results in at least one of the instances 
missing its deadline. So, we have: 

sf= Min sf il . 

t £ Xi 

In the general case, that is, when we wish to find 
the scaling factor for an arbitrary instance / we 
define the following notation (refer to Fig. 6): 


scaling factor sf we follow the same lines as in 
Section 5. Accordingly, the required scaling factor sf 
is given by: 

sf= Min sf‘. 

1 

The interested reader can find examples demon- 
strating the solution presented here in [2], 


• v. U 0 is the used-block that contains the deadline 
of the ( / — l)-th instance of T r If, however, U u is 
a zero-sized block then v is the index of the next 
block following the deadline of the (/ — 1 )-th 
instance at a, + (/— I) X p i + d r As a special 
case, for the first instance v = 1 , 

• q\ Is the block that overlaps with the arrival of the 
/-th instance of task T t . This is also the block that 
contains the completion of the /-th instance. 

• k: U k+i is the block that contains the deadline of 
the /-th instance at a, + (/ — 1) X p j + d r Note 
that, if the deadline does not overlap with a used 
block then we create a zero-sized used-block at 
«, + (/- l)Xp, + d,. k is then given by the 
used-block that precedes this newly created zero- 
sized block. 


The formula for the scaling factor of an arbitrary 
instance (say /) of T i is now given by: 

sf'* Max F m , 

qZm£k 


where F m is given by: 


F m = Min 


( 


Um+\,L Uu.L Um+\.L 

E Ur ’ E u r 


Um+U.-U'j. 

E u, ' 

r — q to m ' 

We now have the scaling factor (sf 0 with respect 
to a task T ( . In order to find the final common 


8. Conclusions 

To summarize the contributions of the paper: 

• We have identified many issues of concern that 
researchers and practitioners face during the de- 
sign, development and maintenance of a complex 
real-time system. 

• We have shown that the questions posed by these 
issues can be formulated from two viewpoints: 
(1) component changes, and (2) task changes. 

• We reduced the above two problems to two fun- 
damental problems viz., schedulability of a task- 
set (on a single component) with arrival times, 
and its scalability. 

• We have presented optimal solutions to the two 
problems. 

Our solution to the problem of end-to-end schedu- 
lability is an important result in that it addresses the 
distributed aspect of real-time systems. Further, the 
solution to the schedulability problem in the context 
of tasks with arbitrary arrivals is an important contri- 
bution to the field of static cyclic scheduling [13]. 
Currently, we are pursuing other applications of the 
results presented in this paper. 

We have found that the scalability result has an 
immediate application to the problem of admission 
control in networks with real-time traffic. The prob- 
lem of admission control is equivalent to asking the 
question: Having admitted (guaranteed) a set of mes- 
sages (n — 1 of them), is it possible to accommodate 
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a new message without violating the guarantees of 
the n - 1 prior messages? Clearly, a simple solution 
would be to perform a schedulability of all n mes- 
sages. However, this is an expensive solution in the 
context of networks. An alternative is to use a heuris- 
tic approach to assess the room to accommodate a 
new message into the network. The heuristic we 
propose to use is based on the scaling factor of the 
n - 1 messages already in the network. This measure 
is then compared against the requirement of the new 
message to decide whether it can be admitted. 

Also research efforts are underway to handle the 
important research issue of deadline division among 
sub-tasks of a task. We are attempting to use the 
scaling factor metric as a heuristic in this process. 
Finally, we are attempting to optimize the scaling 
factor computation for special cases (schedulers) of 
task priority assignments (e.g., RMS, DMS). 
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Abstract 

This paper reports our continuing efforts and initial 
results with the problem of admission control in real-time 
networks. This problem was first addressed by the Tenet 
group, and, their approach was based on the assumption 
that the link level scheduling was EDD (Earliest Due 
Date) based. Our work departs from this assumption 
by addressing the problem in the context of any arbit- 
rary dynamic/fixed priority link level scheduling. Our 
approach is based on extending a result we have derived 
in a different context, viz., Task Scalability. It involves 
assessing the current capacity of a link in terms of its 
ability to accommodate (scale to) new channels. This 
assessment (called the admittance measure) is then heur- 
istically compared against the traffic requirements of the 
newly requested channel to decide its admissibility. A 
simulation study was performed to study the effective- 
ness of our approach in improving both utilization of the 
link and admissibility of channels. Further, we demon- 
strate the relevance of our heuristic by observing that it 
reduces to the Tenet schedulability test, for the case of 
EDD. 

1 Background and Introduction 

Admission control is the mechanism by which mul- 
tiple real-time connections can simultaneously share the 
resources of a packet switching network without result- 
ing in congestion. The connections require guaranteed 
quality of service (QoS) that is initially (at connection 
set up) agreed upon. Admission control comes into play 
when a new real-time connection is being requested. A 
real-time connection request is accompanied with a QoS 
list that describes its requirements. Popular QoS require- 
ments in the literature of distributed real-time systems 
are - throughput, latency (or deadline), packet loss tol- 
erance [2, 4, 6, 7] etc. 
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A popular model used to characterize a real-time con- 
nection is a real-time (RT) channel [10]. An RT channel 
i is characterized by a source and destination (travers- 
ing multiple links) and such parameters as, packet inter- 
generation time (period: ^,), packet size (message size: 
m *) and end-to-end deadline (d,). Derivation of the route 
associated with the connection involves considering both 
static (network topology) and dynamic (already existing 
channels) information. In this paper, we assume that the 
route is given (we are currently investigation the routing 
problem also). The mechanism used to determine the 
admissibility of a real-time channel involves verifying at 
each intermediate link (along the route) in turn, whether 
the RT channel’s QoS requirements can be guaranteed. If 
a channel’s requirements can be met at each of the inter- 
mediate links then we can accept the channel. If however, 
the channel’s requirements cannot be met at any of the 
intermediate link then we can reject the channel. In fact 
the first such link that deems the channel inadmissible 
is sufficient to confirm that the channel would not be 
admissible. Of all the QoS metrics, the latency/deadline 
metric bears the most relevance to real-time systems. We 
therefore restrict ourselves to this metric. 

In order to test whether a channel’s requirements will 
be met at an intermediate link we have to know its dead- 
line and its period at that link. Finding the period 
is straightforward according to the phase adjustment 
mechanism [9]. Phase adjustment is a mechanism which 
allows us to extend the end-to-end period (given by the 
inter-packet generation time) directly to the individual 
links. Therefore, For a given RT channel its frequency 
of arrival at an intermediate link is the same as its fre- 
quency of occurrence at the source. Deadline derivation, 
unlike period derivation is a tougher issue. Since the 
service time of the channel on each of the links is the 
same, one way to derive the deadlines would be to divide 
the slack (given by the difference between the end-to-end 
deadline and the total transmission time of the message) 
of the RT channel equally among the intermediate links. 
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However, if one wishes, one can use a more sophistic- 
ated heuristic [1, 8] to derive these deadlines. We are 
presently also investigating other heuristics. Now, the 
problem of finding the admissibility of an RT channel is 
equivalent to solving the admissibility at each of the in- 
termediate links [3]. Therefore, from here onwards when 
we refer to the admissibility of an RT channel we mean 
its admissibility at an intermediate link. The question of 
admissibility at a link can be described by the following 
test: 

• Admissibility Test : Does the addition of the new 
channel to the already established channels using 
this link cause, either the new channel or one of the 
already established channels to miss their deadline? 

Different approaches to the admission control prob- 
lem (in real-time systems) will differ in the way the above 
question is answered. Therefore, a study in admission 
control reduces to the study of this test. Any answer to 
this question must consider: (i) The scheduling mech- 
anism used at the link, and (ii) Is preemption allowed. 
The Tenet approach assumes the local scheduling mech- 
anism for messages to be based on the Earliest Due Date 
(EDD). While a dynamic scheduling mechanism such as 
EDD gives good performance, its both costly and also 
results in more preemption. The problem of schedulabil- 
ity of messages is analogous to the problem of schedulab- 
ility of real-time tasks (in which context EDD was first 
derived). However, unlike processors where saving the 
state (and restoring it on being re-enabled) of a preemp- 
ted process is simple, the same does not hold in the con- 
text of messages. To the extent possible therefore, any 
approach to message scheduling must minimize preemp- 
tion. 

Having said that the above schedulability test is ana- 
logous to task schedulability we make the following ob- 
servations regarding task schedulability: 

• Schedulability analysis of a task-set is expensive 
(time-wise). The only exception being EDD, which 
has a simple computation that involves checking if 
the resultant (on addition of the new channel) util- 
ization is less than or equal to 100%. 

• For static fixed priority schedulers [5], analyzing 
the schedulability of a task-set involves verifying for 
each task in the order of priority whether it meets 
its deadline. 

• The rate monotonic scheduler (RMS) (a static fixed 
priority scheduler) has a simple schedulability test. 
It involves checking if the resultant utilization is less 
than or equal to n(2 l / n — 1) (where n is the number of 
tasks). This condition is sufficient but not necessary 


for schedulability when deadlines are allowed to be 
less than or equal to task periods. 

The cost involved in doing a precise schedulability 
test as described by Lehoczky in [5] is unacceptable in 
the case of message scheduling. This is primarily due 
to the fact that such a test has to be performed in real- 
time while the channel is being established. Therefore 
any question of admissibility has to be answered in a 
reasonably short time. 

2 Basic Approach 

We discussed how channel admissibility is analogous 
to task schedulability and also the difficulty in using ap- 
proaches to task schedulability directly in the context 
of channels. In this section we present our approach to 
channel admissibility that is based on a problem derived 
in a different context [9, 8] - Task Scalability. The task 
scalability problem can be defined as follows: 

Task Scalability Problem: Given a set of n tasks. 
Find the maximum common scaling factor by which 
the execution times of all the tasks in the set can be 
scaled, without affecting their schedulability. 

Extending this problem to channels and using n — 1 
channels instead of n it reduces to: 

Channel Admissibility: Given a set of n— 1 chan- 
nels. Find the maximum common scaling factor, 
s/„_i, by which the service times of all the chan- 
nels in the set can be scaled, without affecting their 
schedulability. 

The factor s/„_i as defined above is a measure of the 
room in the already established channels for accommod- 
ating new traffic. In our approach to admissibility, we 
use this metric in a heuristic comparison against the re- 
quirements of the new channel whose admissibility we 
are attempting to ascertain. The heuristic comparison 
we use is: 

^ $fn — 1 1 

9n 5 /n — 1 

where, y*L is the utilization (traffic) requirement of the 
new channel. The intuition behind the above heuristic 
will become obvious in the next section. An important 
observation to be made in the use of the above heuristic 
for admissibility is the fact that the scaling factor com- 
putation does not occur at the time of channel request. 
It can be computed immediately after accepting the pre- 
vious channel. This observation is crucial in justifying 
the cost involved in the scaling factor computation. 
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3 Dynamic Scheduling of RT Channels 
In [9] we showed that the common scaling factor in the 
caS e of EDF (assuming periods are equal to deadlines) 
is given by the reciprocal of the total utilization of the 
ftT channels. 

, _ 1 

s Jn-l ~ -v m t 

Z^l<i<n-1 9t 


j Un-l 

1 The term, , in the heuristic described in the pre- 

vious section, can be viewed as the percentage improve- 
ment possible in the utilization of the existing channels. 
The expression can be simplified into the form, 1 — — . 

j m 3 Jn — 1 

[t can therefore be seen, how this heuristic turns out to 
• be equivalent to the deterministic test of Tenet (in the 
context of EDD that is). 

; Table 1, shows a comparison of our approach (us- 
jing the scaling factor) and Tenet’s approach when the 
scheduling mechanism chosen at a link is assumed to be 
I the EDD. 


Approach 

Computation 

Test 

Tenet 

U n 4- U n - 1 + =«■ 

r-H 

VI 

to* 

Scaling 

s fn—\ (precomputed) 

< 1 i 

Sn ~ 1 •/— l 


Table 1: Admission Control Test 

Clearly, Since s/„_i = - , the test in column 3 for 

the Scaling approach reduces to —f* < 1 — U n ~\. Which 
in turn can be rewritten as + U n -i < 1. Which 
is exactly, the admissibility test of the Tenet approach. 
This confirms that, in the context of EDD our approach 
reduces to the Tenet approach. The next section extends 
our approach to general fixed priority link level schedul- 
ing. 

4 Fixed Priority Scheduling of RT Chan- 
nels 

We have shown in [9] that there is no straightforward 
way to compute the scaling factor of a set of tasks (read 
as RT channels in the present context) scheduled by a 
general fixed priority scheduling mechanism. However, 
in the particular case of RMS (again, assuming deadlines 
are equal to periods), we can find a non-optimal scaling 
factor that is given by: 

•jw - »> 

Un- 1 

This factor is not optimal in the sense that it is possible 
to improve it further. In other words, failing to pass 


the heuristic test (using the above factor) does not ne- 
cessarily imply that the new channel will interfere with 
the schedulability of the already existing channels. This 
implies that, using the heuristic it is possible that a new 
channel request is rejected even though it could have 
been accommodated. 

An alternative to the above computation is to use a 
more precise computation, one which would help us ob- 
tain an optimal scaling factor. We have shown in [9], 
how such a computation works. An important consid- 
eration in deriving this result is that deadlines are as- 
sumed to be less than or equal to periods as opposed 
to making a restricted assumption that they are equal. 
This alternative is appealing in its ability to reduce the 
number of rejections (as described in the previous para- 
graph). However, it does not necessarily guarantee 100% 
admissibility. 100% admissibility is said to be achieved 
if the test never rejects a new channel that would have 
not interfered with already accepted channels. The fail- 
ure of this alternative to ensure 100% admissibility is due 
to the fact that though the scaling factor computation is 
precise, the comparison in which it is used is a heur- 
istic. Note also, If the benefit (reducing the number of 
rejections) obtained by using the optimal scaling factor 
is not large enough (compared to using the non-optimal 
computation), we cannot justify its use. Since, the basis 
of the test is a heuristic, the only way one can confirm 
the benefits is to perform a simulation study. 

5 Results 

The following preliminary observations were made 
form the data collected from a simulation 1 performed to 
assess the performance of the heuristic. The two cases 
that were compared are, the heuristic (7£) using the non- 
optimal computation of the scaling factor (Equation 1) 
and the heuristic (5) using the optimal computation of 
the scaling factor reported in [9] . 

• For low utilizations we observe that both the heurist- 
ics have a similar admissibility. Given that the heur- 
istic H. is less expensive (computation time-wise) 
than *5, under conditions of low utilizations one can 
choose the heuristic H. 

• For a given value of n (number of channels) and k 
(parameter dictating the tightness of deadlines) we 
observe that the admissibility of heuristic 7 Z falls ab- 
ruptly beyond a point given by the utilization bound. 
For example, when n = 8 and k = 60, the heuristic 
V, begins to reject channels when the total utilization 
crosses beyond 72%. 

• The performance of S degrades gracefully beyond 
the utilization bound. For example, when tx = 8 

1 The plots from the simulation study are not included here due 
to space restrictions 
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and k = 80 the heuristic S continues to admit chan- 
nels up to a total utilization of 92%. The probabil- 
ity of acceptance decreases gradually (and steadily) 
however. This implies that the heuristic has a better 
ability to adapt to temporary overloads (increased 
demand from one of the channels) in the network 
traffic. 

• As the number of channels increases, the perform- 
ance degradation beyond the utilization bound is 
slower in the case of heuristic 5. This goes on to 
support the ability of the heuristic to adapt to tem- 
porary overloads (increase in the number of chan- 
nels). The two sources of overload have been suc- 
cessfully handled by the heuristic S . 

• As the number of channels increases the success of 
the heuristic S improves compared to the heuristic 
72. 

• S has better performance with respect to rejecting 
inadmissible channels compared to 72. Thus proving 
the sensitivity of the heuristic and its ability to avoid 
incorrect admissions. 

• In conclusion we can say that for low utilizations 
both heuristics have similar performance (however 
one should prefer the heuristic 72 due it computa- 
tional ease) but, at high utilizations S far outper- 
forms 72. Further, we can justify the cost of com- 
putation involved in S by noting that the computa- 
tion can be done before the actual channel request 
is made. 

6 Conclusions and Future Work 

A significant contribution of the work reported in this 
paper is a heuristic based admission control mechan- 
ism that can be applied for any arbitrary scheduling 
mechanism. The schedulers considered spanned both dy- 
namic (EDD) and static (RMS) schedulers. Further, in 
the static scheduling scenario, we can easily extend the 
admission control mechanism to any fixed priority as- 
signment. The need for being able to accommodate any 
arbitrary priority assignment arises from the fact that 
channels derive their importance (and so their priority) 
from the inherent purpose they serve relative to other 
channels and not by their demands (as characterized by 
the parameter deadline in EDD and the parameter peri- 
odicity in RMS). 

In the treatment of the admission control problem 
above, we have assumed that the route that a channel 
traverses is given to us. We are currently investigating 
mechanisms by which such a route can be built. The 
mechanisms can exploit the seeding factor problem de- 
scribed before. As described already the scaling factor 
for a link’s traffic (corresponding to the factor with which 


the requirements of channels already passing through the 
link can be scaled) gives a measure of the available room 
in the link with regards to accommodating new chan- 
nels. We can use this measure in building the route to 
be traversed from a given source to destination. We are 
considering two alternatives here: (i) Source routing, and 
(ii) Hop-by-Hop Routing. 

An important research issue that was alluded to in 
section 1 was the derivation of a channel’s deadline at in- 
termediate links. We presented one approach to this de- 
rivation that simply divides the deadline equally among 
the links. It is our belief however, that this problem 
needs further investigation and therefore has been, the 
subject of our current research. 

The heuristic used in comparing the new channel’s re- 
quirement against the links current load (characterized 
by the scaling factor) was shown to work well in the con- 
text of dynamic schedulers. However, in the context of 
static schedulers, it is our belief that the heuristic needs 
further validation. 
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The number and complexity of applications that run in real-time environments 
have posed demanding requirements on the part of the real-time system de- 
signer. It has now become important to accommodate the application com- 
plexity at early stages of the design cycle. Further, the stringent demands to 
guarantee task deadlines (particularly in a hard real-time environment, which 
is the assumed environment in this thesis) have motivated both practioners 
and researchers to look at ways to analyze systems prior to run-time. This 
thesis reports a new perspective to analyzing real-time systems that in addi- 
tion to ascertaining the ability of a system to meet task deadlines also qualifies 
these guarantees. The guarantees are qualified by a measure (called the scaling 
factor) of the systems ability to continue to provide these guarantees under 
possible changes to the tasks. This measure is shown to have many applica- 
tions in the design (task execution time estimation), development (portability 
and fault tolerance) and maintenance (scalability) of real-time systems. The 
measure is shown to bear relevance in both uniprocessor and distributed (more 
generally referred to as end-to-end) real-time systems. 



However, the derivation of this measure in end-to-end systems requires 
that we solve a fundamental (very important, yet unsolved) problem — the end- 
to-end schedulability problem. The thesis reports a solution to the end-to-end 
schedulability problem which is based on a solution to another fundamental 
problem relevant to single-component real-time systems (a uniprocessor system 
is a special instance of such a system). The problem of interest here is the 
schedulability of a set of tasks with arbitrary arrival times, that run on a single 
component. The thesis presents an optimal solution to this problem. One 
important consequence of this result (besides serving as a basis for the end- 
to-end schedulability problem) is its applicability to the classical approach to 
real-time scheduling, viz., static scheduling. The final contribution of the thesis 
comes as an application of the results to the area of real-time communication. 
More specifically, we report a heuristic approach to the problem of admission 
control in real-time traffic networks. The heuristic is based on the scaling factor 


measure. 
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Chapter 1 


Introduction 


The scope of real-time systems has expanded over the last two decades to en- 
compass a wide array of applications such as industrial process control systems, 
nuclear power plants, air traffic control systems, aircraft navigation, robot nav- 
igation and automobile control. While, in the past these systems were predom- 
inantly centralized, most current approaches tend to be distributed in nature. 
Further, the complexity of these systems (in addition to that added by its 
distributed nature) has grown rapidly to a point where the dependability (or 
determinism) of the system as a whole has become an important issue. Real- 
time systems are primarily categorized into two types, hard real-time systems 
and soft real-time systems. In hard real-time systems, the missing of task dead- 
lines can lead to severe consequences and hence there is a strict need to meet 
these deadlines. In contrast, soft real-time systems are characterized by the 
fact that they can tolerate temporary deadline misses. Soft real-time systems 
continue to operate even after missing deadlines, and the only consequence 
being a temporary decline in performance and an increase in response time. 
For example, a robot operating in a hazardous terrain would be a hard real- 
time system and a system that periodically generates a weather report can be 
considered a soft real-time system. 


1 
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The stringent need to meet deadlines in hard real-time systems implies 
that there is a need to analyze the system pre-runtime, to ascertain its ability 
to guarantee performance (that is meeting deadlines). Therefore, this has mo- 
tivated enormous efforts from practioners to investigate the system behavior 
prior to its actual installation. In other words, though the system is said to 
function in real-time, the guarantees it provides in meeting the timing require- 
ments of the various tasks have to be ascertained a priori. This thesis presents 
issues and finds solutions that we believe will aid practioners in guaranteeing 
system behavior prior to run-time in hard real-time systems. The issues in 
soft real-time systems overlap significantly with those in conventional systems 
where the primary performance metrics are throughput and response time (an 
average measure unlike deadline that is an absolute measure). These systems 
have been well-studied and the results (pertinent to these systems) are directly 
applicable to soft real-time systems. 

A real-time system can be characterized by two important components: 
the environment in which the system is operating and the computer system 
that controls/monitors the environment. The main issues in the design of the 
first component concern interfacing with the environment [ 41 ]. Solutions in this 
area are primarily dictated by the technology. There are many issues of concern 
in the design of the second component, the computer system. The computer 
system involves both the hardware and the software that runs on them. The 
choice of hardware is dictated primarily by such parameters as cost, availability 
and the application at hand. The primary issue in software design is not so 
much the particular choice of language or programming paradigm as it is the 
mechanism by which the various tasks are scheduled. 
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1.1 Issues in Real-Time Systems 

We observe that only the last issue (mentioned above) can be speculated over 
because the others are more or less dictated by the environment and the ap- 
plication at hand. This is the reason why we have efforts from numerous 
researchers [40, 48] on the problem of scheduling in real-time systems. There 
have been two important fronts of research: On one front there have been 
efforts [2, 20, 22, 24] to find scheduling mechanisms that could guarantee per- 
formance under different assumptions about the system. On a second front, 
researchers [46, 19, 3] have tried to answer questions posed by schedulability 
analysis. Both these are inter-related in the sense that schedulability analysis 
is a mechanism to evaluate the effectiveness of a scheduler. To this end, in the 
following discussion when we refer to schedulability we implicitly assume that 
the tasks are being scheduled by an arbitrary scheduler (where appropriate, 
we give a more detailed description of the scheduler assumed). If a scheduler 
is built on a strong theoretical basis then its schedulability analysis can be a 
trivial comparison. For example, a dynamic scheduling mechanism, the earli- 
est deadline first (EDF) scheduler, has the theoretical property that, provided 
the sum of the utilizations 1 of the tasks in a task-set is less than 1, the EDF 
scheduler guarantees to meet their deadlines (schedulable). Clearly, in this 
case the schedulability test is a simple one. There are other cases where the 
schedulability test is non-trivial [19, 50]. 

A common assumption that distinguishes one scheduling mechanism 
(and thus the corresponding schedulability analysis) from another is the oper- 

'The utilization of a periodic task is given by the ratio of its execution time requirement 
to its periodicity 
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ational environment of the real-time system. If the environment is completely 
known a priori, then we can use a static approach to design a scheduler. The 
schedule can be practically pre-computed (as a list), with the scheduler be- 
ing a simple mechanism to pick the next task in the list. On the other hand, 
if the environment is dynamic by nature and no a priori knowledge can be 
assumed about the environment then the scheduling mechanism must be dy- 
namic, adapting to the changing needs of the system. Clearly, a dynamic 
scheduler is more expensive (in terms of overhead) to implement compared to 
a static scheduler. 

The use of dynamic approaches are perfectly justified in systems where 
the various internal (system) and external (environment) tasks characteristics 
are not known a priori [40]. However, we observed that such systems are far 
outnumbered by those where the environment is well understood, deterministic 
(in the sense that the worst possible scenarios can be identified), and with tasks 
whose timing, resource, communication and other requirements are known a 
priori [49]. This thesis addresses a host of related problems that concentrate 
on such static environments. 

1.2 Issues Addressed in this Thesis 

The problems of interest to us in this study are motivated by the evolutionary 
nature of real-time system software. As real-time systems continue to grow 
in size and scope there is a need to build portable standard software that 
would be guaranteed to operate correctly both in the logical and the temporal 
sense. By correctness in the logical sense, we are referring to the domain 
of proving the correctness of a piece of software with regards to generating a 



D 


correct output for any given input (The traditional program correctness issues). 
The emphasis of research in real-time systems has been not so much to prove 
logical correctness as it has been to show that the output is produced in a 
timely manner. Therefore, a logically valid output generated beyond a specified 
time limit is deemed incorrect. In this thesis, we concentrate primarily on the 
temporal correctness. 

This notion of correctness (temporal that is) of a task in real-time sys- 
tems has been captured by the concept of schedulability [46] of tasks. A task 
is primarily characterized by the following parameters: the arrival time, the 
execution time, the periodicity and the deadline. Schedulability analysis there- 
fore attempts to ascertain whether or not each task will be able to complete 
its required execution before its deadline for all its instances when scheduled 
by an assumed scheduler. Tasks being periodic, they occur repeatedly at an 
interval given by their period. Various such occurrences of tasks are referred to 
as instances. The basic approach taken in schedulability analysis is to use the 
information about tasks’ arrival times, execution times and periodicities and 
compute their worst-case completion times assuming that they are scheduled 
by a given scheduler. The worst-case task completion times so computed are 
compared against their deadlines to determine if the tasks will be schedula- 
ble. Therefore, the worst-case completion time computation is the essence of 
schedulability analysis. 

We are not interested in deriving new schedulability tests but rather in 
extending the guarantees made by schedulability analysis as a system undergoes 
changes. The types of changes we are mainly interested in, manifest themselves 
as changes in execution times of tasks. In Chapter 3 we discuss sources of such 
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changes pertinent to the design, development and maintenance of real-time 
systems. More specifically, we are interested in the effects on the guarantees 
made by schedulability analysis when some or all of the tasks’ execution times 
are scaled (up or down) 2 . We refer to this problem as scalability of real-time 
systems. There are two important scenarios in which the factor has relevance: 
(i) Uniprocessor systems and (ii) end-to-end systems. 

The problem of scalability in uniprocessor systems can be informally 
defined as follows: 


Given a task-set T , determine the maximum scaling factor with which 
a subset (S) of these task-set’s execution times can be scaled without 
affecting the schedulability of the task-set. 

If a task-set is not-schedulable 3 to start with then scaling a subset of 
the task will in no way improve the situation and this case is of no interest to 
us. On the other hand, if a task-set is schedulable to start with, then we are 
guaranteed the existence of a scaling factor (possibly 1, in the case that the task- 
set requirements are tight) that does not affect the task-set’s schedulability. 
The first step therefore is to find whether the given task-set is schedulable. 
In the context of uniprocessor systems, Lehoczky’s [19] schedulability test can 
be used for this purpose. Finding the scaling factor now can be viewed as 
extending this schedulability test to accommodate for changes in task execution 
times. There are two possible approaches here: (i) using an approximation 

2 Scaling down of task execution times can be trivially handled, therefore from here on- 
wards when we refer to scaling we mean scaling up 

3 That is, at least one of the tasks misses its deadline when scheduled by the assumed 
scheduler. 


technique by making small increments to the scaling factor (starting from 1) 
and repeatedly performing the schedulability test, or (ii) embedding the scaling 
factor computation into the schedulability test. We have taken the second 
approach for performance reasons that will be described in detail in chapter 4. 

As opposed to uniprocessor systems where we have a single schedulable 
resource, end-to-end systems (e.g., a distributed system) have more than one 
schedulable resource. Therefore an end-to-end system can be characterized by 
tasks that do not necessarily execute on a single component 4 . Typically, a task 
would comprise of a sequence 5 of sub-tasks that each execute on a different 
component (e.g., processors, network) in the system. The requirements of 
period, deadline and arrival time are specified for the task as a whole with the 
execution times being specified at the sub-task level. The problem of finding 
the schedulability (worst-case completion time computation) of a task (T,) in 
such a scenario can be reduced to solving the schedulability of the m (number 
of sub-tasks in task T,) sub-tasks in turn, provided we are able to compute 
the characteristics (period and arrival time) of the sub-tasks (T,k 1 < t < 
n; 1 < k < m). For reasons that will become clear in chapter 3, we cannot 
use Lehoczky’s schedulability test for the sub-tasks running on these individual 
components. 

The scalability problem in the context of end-to-end systems takes two 
forms depending on whether we view the scaling to occur as a result of a 
change in one or more of the components or a change to a subset of the sub- 
tasks. Solving either of these two forms requires that we first find whether the 

4 We use the term component to indicate any schedulable entity in the system. 

5 The treatment in this study is restricted to sequential tasks, however, it can be extended 
to more complex tasks. 
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given task-set (of end-to-end tasks) is schedulable to start with (we call this 
end-to-end schedulability). Secondly, we have to extend this schedulability test 
to accommodate component and/or task changes. 

We have investigated the applicability of the scalability problem in other 
areas of real-time systems. Particularly, in the area of real-time communica- 
tion. The application of interest to us is admission control in real-time (RT) 
channels [9, 8]. The role of real-time channels in communication is analogous to 
end-to-end tasks in distributed systems. Admission control poses the question: 
“Having guaranteed the performance requirements of n — 1 real-time channels, 
is it possible to admit a new real-time channel, while continuing to honor the 
guarantees already made?” The problem of admission control is analogous to: 
“Given a schedulable task-set of n — 1 end-to-end tasks, is it possible to ac- 
commodate a new task without violating the schedulability of the n — 1 prior 
tasks?” 


1.3 Summary of Results 

The primary contribution of this thesis to the area of real-time systems is 
in presenting solutions to the following two fundamental problems related to 
schedulability analysis. The first of these problems involves schedulability anal- 
ysis of task-sets where tasks have non-zero arbitrary arrival times. The second 
involves extending schedulability analysis to accommodate scaling up of task 
execution times. The impact these problems (and their solutions) have on 
the current state-of-the-art of real-time system research can be summarized as 
follows: 



• Helps real-time system designers in doing a precise analysis of task-sets. 
Such a precise analysis, as opposed to the pessimistic analysis approach 
that was popularized by the RMA [6] (Rate Monotonic Approach) group 
at SEI helps prevent under-utilization of system resources. 

• The thesis identifies many important issues in real-time systems that mo- 
tivate the need for using the arrival time information of tasks in schedu- 
lability analysis. Prominently, the issues of data and resource sharing 
among tasks, precedence constraints between tasks, controlling task jit- 
ter can be addressed naturally by the use of task arrival times. 

• The use of static schedules was popular in practice in real-time systems till 
the late 70s. The approach however, suffered from the inability to guar- 
antee task schedulability a priori as opposed to RMA, which was based 
on the critical instant argument. As a by-product of doing a schedulabil- 
ity analysis of task-sets with arrival times (reported here), we are able to 
build static schedules whose ability to guarantee task schedulability can 
be ascertained a priori. 

• There is no known schedulability analysis approach in the context of dis- 
tributed real-time systems (or more generally end-to-end real-time sys- 
tems). Using the single-component schedulability analysis of tasks with 
arbitrary arrivals, we are able to perform an end-to-end schedulability 
analysis. 

• The thesis reports the first effort in addressing the issues of scalability 
and portability in real-time systems. 
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• The scaling problem is shown to help address issues of concern to de- 
signers in the design, development and maintenance real-time systems. 
In the design phase it allows us in analyzing the task-set by assuming 
an arbitrary target environment which can be later adapted to a specific 
target environment. In the development phase it allows us to add new 
tasks or enhance the existing task’s functionality. In the maintenance 
phase it helps address the ability of the system to tolerate faults. 

• The scalability problem is also solved in the context of distributed sys- 
tems. 

• Lastly, we report a heuristic approach to the problem of admission control 
in real-time traffic networks. The heuristic used is based on the study of 
the scaling factor problem. 

1.4 Organization of the Thesis 

The rest of the chapters of the thesis are organized as follows. Chapter 2 lays 
down the framework and terminology used through the rest of the paper. We 
describe the uniprocessor system model and task characteristics of interest to 
us. The special sense attributed to the arrival time parameter leads to the 
consideration of dependent and independent task-sets. The end-to-end system 
model is defined both in a restricted flow-shop sense and also a more generalized 
sense. Finally, the real-time channel model used in the study of admission 
control in real-time traffic networks is described. 

In Chapter 3, we give a brief discussion on some theoretical background 
in scheduling that is pertinent to this thesis. In particular we discuss the 
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work of Lehoczky in the context of schedulability analysis of fixed priority 
schedulers. The use of the critical instant argument and its consequences in 
both uniprocessor and end-to-end systems is critiqued. We also discuss the 
limited work reported in the areas of end-to-end scheduling and admission 
control. 

In Chapter 4, the problems of interest in this thesis are formally stated 
and their solutions are shown to reduce to solving three fundamental problems 
that are the subject of the next four chapters. Chapter 5 presents the problem 
of uniprocessor scalability. A pre-requisite to solving the end-to-end scalabil- 
ity problem is the end-to-end schedulability problem which is the subject of 
Chapter 6. Chapter 7 considers the end-to-end scalability problem from two 
different perspectives viz., component change and task change. 

The problem of admission control of real-time channels is the subject of 
Chapter 8. Here, we discuss a simulation study to compare two heuristics to 
solve the admission control problem. 

Finally in Chapter 9, we describe a detailed example that puts the 
reported results in perspective and also concludes this thesis. The chosen ex- 
ample is derived from the case study of the “Olympus Attitude and Orbital 
Control System” (AOCS). This case study was performed by Alan Burns and 
his colleagues at University of York in association with British Aerospace Space 
Systems Ltd. for ESTEC. 



Chapter 2 


System Model 


In this chapter, we introduce the modeling assumptions and establish the no- 
tation and terminology used in the rest of the thesis. We identify three models 
relevant to the thesis viz., uniprocessor system model, end-to-end system model 
and real-time channel model. 


2.1 Uniprocessor System Model 

The uniprocessor system model is characterized by the fact that there is only 
one allocatable component in the system, viz., the processor. More generally, 
this model can be referred to as “single component model .” 1 The role of the 
processor is to monitor/control the target environment. For example, if the en- 
vironment is that of a chemical experiment, then the processor interacts with 
the environment through sensors and actuators. The sensors serve to convey 
the current information about the experiment as inputs to the processor. These 
inputs together with locally (local to the processor) maintained state informa- 
tion capture the state of the experiment. The processor performs predetermined 

'The term component is used to refer to any independently schedulable resource. Ex- 
amples include, processors, communication medium, input/output processors, disk storage 

etc. 
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operations on these inputs (along with the information) and generates outputs 
that are then conveyed to the experiment through the actuators. Therefore, 
the interaction of the processor with the environment in which it operates can 
be captured by the inputs and outputs. 

The operations which process the inputs to compute the outputs are 
contained in the tasks. In addition, to tasks that operate on the external inputs, 
we can also have tasks that are triggered solely by internal events or timed 
events. The operation of the complete system can be captured by specifying 
the characteristics of its tasks. There is one distinguishing characteristic about 
tasks that affect the complexity of the system, viz., task dependence. We 
therefore identify the following two cases separately. The following description 
applies for both these scenarios: 

Here, n independent tasks, {T\, T 2 , . . . , T n }, capture the activity per- 
formed on a processor. Each task (t is called the identifier of the task T,) is 
characterized by the following parameters: 

• e,: The execution time requirement of a task. Note that if we look at the 
model as a “single component model” then this parameter could mean 
the service time requirement of the task from the component in question. 

• ai\ The arrival time of the first instance of a task. This parameter is also 
referred to as the offset of the task. Given a task-set T we can assume 
that the task that is the earliest to arrive (say a min ) does so at time t = 0 
(o mm = 0). Therefore all other task arrival times are relative to this 
reference. 



14 


• pi : The periodicity of a task. Consistent with the assumptions of re- 
searchers in real-time systems, we assume that tasks are of a periodic 
nature. This parameter implies that a task would be ready for execution 
every p , units of time. We refer to successive occurrences of a task as its 
instances or jobs. Therefore the j th instance of task T x will be referred 
to as Tj. As opposed to periodic tasks, aperiodic tasks are characterized 
by the fact that they are not strictly periodic. However, the minimum 
inter-arrival time between successive occurrences of an aperiodic task is 
assumed to be known. Note that in case the task is an aperiodic task we 
treat this parameter (p,) to be the minimum inter-arrival time between 
the task’s successive instances. 

• d x \ The deadline of a task. Every instance of a task is required to complete 
its execution before the task deadline. Therefore, if the first instance of 
a task T, arrives at time t = 0 then its deadline is at time t = d t . 
Subsequently, the j th instance will arrive at time t = a, + (j — 1) x p, 
and will have its deadline at time t = a, (j — 1) x p^ + d{. Throughout 
the study, we assume this parameter of a task to be less than or equal 
to its period. In other words, the completion of a task’s instance can be 
delayed at most till its next instance arrival. In this study we assume 
this to be a hard deadline. This assumption can be justified as follows: 
The problems we are interested in, involve schedulability analysis which 
is typically done offline and before the actual system is built. If the 
offline analysis would show that a task’s deadline cannot be met, then 
the factors that the analysis failed to account for (compared to the real 
system) would make the task’s chances of meeting its deadline only worse. 


Therefore it would seem only logical to assume the deadline to be a hard 
deadline. 

• Pr t : The relative priority of the task in the system. We assume that every 
task has a priority assigned to it. The priority could be dictated either by 
the scheduler (e.g., the rate monotonic scheduler assigns priorities to tasks 
based on their periods) or by the inherent importance of the task relative 
to other tasks in the system. Unless specified otherwise, we assume that 
the tasks are ordered in the non-increasing order of their priorities. A 
simple transformation can convert this non-increasing order to a strictly 
decreasing order. For example consider a task-set, T containing 5 tasks 
with priorities, Pr\ = 9,Pr 2 = 8 , Pr 3 = 8 , Pr 4 — 4, Pr s = 2. Tasks 
T 2 and T 3 have the same priority. Since equal priorities are arbitrarily 
broken, we can reassign TVs priority, (say to 6 ) to be smaller than 7Ys 
(we use task identifiers to break conflicts between tasks). Note that if Pr 5 
was equal to 7 and the priorities had to be integers then we cannot assign 
a new priority to T 3 . In such a case we can reassign new priorities to T 4 
and T h in order to make room for T 3 . In other words, the transformation 
guarantees that the first task Ti is the highest priority task and the 
priority of task X) is greater than Ti if and only if j < i. 

• W t : The worst-case response time. This is also referred to as the worst- 
case completion time of task T,. This term gives the worst possible time 
elapsed between an instance of the task TC s arrival and its corresponding 
completion. Clearly, if the response time of the j th instance of the task 
T, was Wf then, W, is given by the maximum W l Vj. 
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The characteristic that distinguishes the two scenarios of independent 
and dependent tasks arise from assumptions about the arrival time parameter. 

2.1.1 Systems with Independent Tasks 

The arrival time a, is the arrival of the first instance of a task. Task indepen- 
dence is primarily captured by assuming that the arrival times of tasks do not 
have any interdependence. Therefore leading to the assumption that the arrival 
times of all tasks are equal to zero. This assumption has a significant impact 
on the study of task schedulability. It allows us to use the critical instant ar- 
gument. The critical instant argument is used in finding the schedulability of 
the rth task among n tasks scheduled by a fixed priority scheduler. It can be 
briefly summarized as follows: 

A task T, suffers its worst-case completion time (or response time) when 
its arrival coincides with the arrival of every other higher priority task 
Tj (i < j < 1). Such an arrival is called a critical instant for the task T,. 

It is important to understand that the occurrence of the critical instant 
for a task Ti is not mandatory, in the sense that given a task-set (of tasks with 
arbitrary arrivals) a task is not guaranteed to encounter its critical instant. To 
this end, we assume that the arrival times of tasks are given to be zero, thus 
forcing the occurrence of the critical instant. Therefore, the critical instant 
argument is sometimes referred to as the critical instant assumption. 



2.1.2 Systems with Dependent Tasks 

The case for considering task dependence has been addressed by many re- 
searchers in different contexts [49]. Krithi Ramamrithm, in his discussion [41] 
on the complex nature of real-time environments states that, task interdepen- 
dence contributes significantly to the complexity. Alan Burns makes similar ob- 
servations in the context of the case study on the Orbital Control System [5]. 
Here, we briefly list some situations that impose task dependence. We also 
identify how these different situations can be addressed by incorporating the 
offset (arrival time) parameter defined in the previous subsection. 

• Data and Resource Sharing: It is important to regulate the accesses of 
multiple tasks to a shared data item or resource. A costly solution to this 
problem is to implement a concurrency control mechanism (such as the 
priority ceiling protocol [33]). As an alternative to using a concurrency 
control mechanism, we observe that by inhibiting two or more tasks from 
accessing a resource simultaneously we can regulate their access [45]. Such 
an inhibition can be achieved by deriving suitable arrival times (offsets) 
for tasks. For example, if two tasks, T, and Tj, access a common resource 
(or data item) then with the knowledge about their expected duration of 
use of this shared resource one can arrive at their relative arrival times. 
These arrival times can be computed such that the request by Tj always 
follows the release by T t . In other words, we can impose constraints on 
the tasks to the effect that their accesses to the shared entity are ordered. 
This situation can be described as an exclusion constraint that was solved 
by imposing a precedence order on the tasks. 
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• Precedence Constraint: If the tasks inherently possess a precedence con- 
straint, then it would directly manifest itself as an offset in each task. 
For example, if the partial results (outputs) generated by a task T, are 
used (as inputs) by a second task Tj, then we are forced to impose the 
condition that the task Tj will be ready to execute only after T, com- 
pletes. Therefore, there is an inherent precedence constraint on T } . The 
conveyance of these partial results can be done either through shared 
memory or through communication. Thus, inter-task communication can 
also impose precedence constraints. 

• Controlling Task Jitter: The irregularity in the response times (different 
instances) of a task T± can hurt the schedulability of tasks that depend 
upon its output [27]. This entails an output jitter bounded (from above) 
by the difference of the worst-case response time and the task’s execution 
time. The output jitter of a given task Xi can be reduced by dividing 
it into two tasks T } and 7*. Tj performs the bulk of the execution and 
writes the results to a buffer shared by Tj and T^; 7* is released at an 
offset from task Tj that is large enough to ensure that the data is always 
available. This approach can also be used to bound jitter on input [45], 

From the above discussions it is clear that, task dependence can be 
captured by the notion of timing offsets for tasks. Further, given a task-set 
and the details of inter-task dependencies, we can arrive at individual task 
arrival times. 
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2.2 End-to-End System Model 

This model differs from the uniprocessor system model (single component 
model) in that it considers more than one independently allocatable compo- 
nent in the system. A task in such a system can require execution on multiple 
components. Hence, a task is no longer viewed as an indivisible entity but as 
a sequence of sub-tasks. We assume that each sub-task of a task is associated 
with a component. Therefore a task that uses r components is decomposed into 
r sub-tasks, one corresponding to each component. A discussion of reasons and 
guidelines for task-decomposition can be found in [49]. 

We assume that the components in the system are ordered. The tra- 
ditional flow-shop model [4] is based on the assumption that all tasks in the 
task-set access all resources and that they do so in the same order. A more gen- 
eral view to flow shops would be to relax the requirement about tasks having to 
access all resources but still maintaining the order constraint. This model will 
be referred to as the ordered flow shop model. If there are m components in 
the system, R \ , R 2 , . . . , Rm, then a task T, can be considered to be a sequence 
of sub-tasks T ix — * Ta —< - . . . — * ► T im . In the case of traditional flow-shop model, 
each sub-task T,k is required to have a non-zero execution time requirement on 
the component it runs. Ordered flow shop model relaxes this constraint. 

A sub-task Tik of task T t is characterized primarily by its execution time 
requirement on the component (Rk) it runs. In the case of the ordered flow 
shop model, if a component k is not used by a task T, then the execution 
time requirement of the task T t k is assumed to be zero. The parameters of 
periodicity and deadline are characteristics of a task and not that of the sub- 
tasks. Since these parameters apply to the task as a whole (from the start 
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of the first sub-task to the end-of the last sub-task) we refer to these as the 
end-to-end parameters of the task. The last parameter associated with the task 
is its priority Pr x which may be inherited by its sub-tasks. Alternatively, we 
can allow individual sub-tasks of a task to be assigned priorities independently. 
Unless otherwise specified, throughout this study, we assume that sub-tasks of 
a task inherit its priority. 

2,3 Real-Time Channel Model 

The two models described above are computational models. The real-time (RT) 
channel model however is a communication model that abstracts the commu- 
nication activity in real-time packet switched networks [42, 38]. A real-time 
channel is uni-directional 2 . An entity (say a process) wishing to communicate 
with another entity on a remote machine does so by establishing a real-time 
channel that has certain characteristic timing and buffer space requirements. 

A real-time (RT) channel timing requirement can be defined by the 
following parameters: 

• The minimum message inter-generation time 

• A maximum message size 

• An end-to-end deadline for the RT channel 

It is reasonable to assume prior knowledge of these parameters for 
many applications such as real-time timing control and monitoring, interac- 

2 A bi-directional R-T channel can be created by combining two uni-directional RT- 
channels [54] 
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tive voice/video transmission and many other multimedia applications. In ap- 
plications where these parameters are less predictable, estimates can be used. 
Note that any guarantees that the underlying communication subsystem pro- 
vides to the application is sensitive to the ability of the application to correctly 
specify its requirements. In this thesis, we are not interested in how such a 
correct specification is achieved, but given such a specification, how does the 
underlying system guarantee its being met. 

Formally, an RT channel can be defined as follows [53]: 

Definition 2.3.1 A real-time channel C{ described by a tuple (g,m<d) is a 
connection between two nodes and require that every message at the source be 
delivered to the destination in duration of time no longer than d, under the 
conditions that the message inter- generation time is g, and the message size is 
m. 


This definition of an RT channel helps in network management and also 
provides a convenient means of charging users for their connection requests. For 
example, a user will pay lower connection fee for a voice channel than a video 
channel since the former uses less bandwidth. A connection that demands a 
low end-to-end delay (or deadline) is likely to cost more than one that tolerates 
a higher end-to-end delay (or deadline). 

2.4 Glossary of Notation 

The following table summarizes the notation used throughout the thesis. 



Table 2.1: Glossary of Notation 


Notation 

Description 

t 

Time 

T 

A task-set 

Ti 

The i th task in a task-set T 

a, 

The arrival time of the first instance of task Ti 

e, 

Execution time of task Ti 

p. 

Period of task Ti 

d x 

Deadline of task T x 

Pr> 

Priority of task Ti 


Worst-case response time of task Ti 

7V 

The j th instance of task Ti 

ai 

Arrival time of the j th instance of task T{ 

di 

Deadline of the j th instance of task Ti 

w\ 

The response time of the j th instance of task T t 

T, k 

The k th sub-task of task T, 

Oik 

Arrival time of the first instance of task T k 


Execution time of the sub-task 7** 

Pik 

Period of sub-task T»*, if known 

dik 

Deadline of sub-task T tj t, if known 

Pr, k 

Priority of sub-task Ti k 

w ik 

Worst-case response time of sub-task Tik 

Rr 

The component with an assigned index r in the system 

Ci 

Real-time channel i 

9i 

The inter-message generation time of RT channel C, 

m x 

The maximum message size of RT channel Ci 

di 

The end-to-end deadline of RT channel Ci 



Chapter 3 


Motivation and Relevant Background 


We are interested in extending the current schedulability analysis to accommo- 
date changes in task execution time. It is only befitting to spend some time 
in describing the principles and assumptions that underlie this analysis. Most 
schedulability results [24, 19, 44, 46] are based on the critical instant argument, 
which defines a worst-case condition for a task. Clearly, a task suffers its worst 
completion time when it has to compete for the processor (or component in 
question) with every higher priority task in the system. That is, when it ar- 
rives at a time when all other higher priority tasks also arrive. This instant is 
called the critical instant. Therefore, it is sufficient to look at the completion 
time of this one instant in order to ascertain the task schedulability. But does 
this computation really give us the worst-case completion time of a task? In 
other words, given a task’s characteristics, will it ever suffer this completion in 
reality? 

Notice that the critical instant argument clearly ignores the arrival in- 
formation of tasks and makes the assumption that, sooner or later at least 
one of the instances of a task will face a critical instant. It can be seen, 
however, that this is not necessarily true and therefore, the actual worst-case 
completion time of a task can be less than or equal to the completion time 
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computed by the critical instant assumption. A simple example will clarify 
this point: Consider a task-set with two tasks, T\ and T 2 whose characteristics 
are, a i = 0,ej — 2,p\ = 12, d\ = 10 and a-i = 3, t-i — l,p 2 = 12,^2 = 9 respec- 
tively. Further assume that T\ is the task with the higher priority. Clearly, 
task T 2 will never encounter a critical instant because, its every instance will 
be ready only 3 units of time after the arrival of T x . Further, T } needing only 
2 units of execution time will complete before T 2 s instance is ready. In this 
scenario, the worst-case response time of task T\ will be 2 and that of T 2 will 
be 1. Ignoring the arrivals and using the critical instant argument will result 
in T 2 s worst-case completion time being computed as 3 and not 1. Therefore, 
ignoring the arrival times of tasks and using the critical instant argument leads 
to a pessimistic computation. 

Can we tolerate the pessimism inherent to this computation? The an- 
swer to this question depends on the environment under consideration, viz., a 
uniprocessor or a distributed (more generally end-to-end) system. In unipro- 
cessor systems, depending on the assumptions (task independence for example) 
made, practioners [6] have argued that the cost of finding a more precise mea- 
sure of the task completion time far outweighs the benefit gained (say, in terms 
of saved resource utilization). However, there are convincing arguments to the 
contrary by Tindell in [45]. He discusses scenarios that show the importance of 
considering the task arrival information in schedulability analysis 1 . We believe 
that the importance can be really felt in end-to-end systems and in unipro- 
cessor systems with dependent tasks and not so much in uniprocessor systems 
with independent tasks. 

'Look at the discussion in Chapter 2 about dependent and independent tasks. 
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Now, let us look at the problem of schedulability analysis in end-to- 
end systems. The schedulability of a task in an end-to-end system can be 
reduced to a sequence of uniprocessor schedulability problems provided we are 
able to compute the characteristics (period and arrival time) of the sub-tasks. 
Let us assume for now that we have a mechanism to compute the sub-task 
periodicities (the mechanism will be described in detail later). We don’t require 
the arrival time information if we follow the critical instant argument, since 
we are going to ignore it anyway. We can use the critical instant argument 
(ignoring the arrival time a ,/e) to find the worst-case completion times of all 
sub-tasks 7)* (1 < k < m). Clearly, the worst-case completion time of the task 
T, is given by the sum of the worst-case completion times computed above. 
Observe that we have a cumulative measure of pessimistic computations that 
is bound to be more pessimistic. Therefore, we can see that even if one can 
tolerate the pessimism inherent in the critical instant argument, in the context 
of uniprocessor systems, we cannot do so in the context of end-to-end systems. 

Before we give a description of the problem we are interested in address- 
ing in this study, we would like to motivate the reader by briefly discussing the 
source of the problem. In the chapter 1, we mentioned that the kinds of changes 
(that interest us) that systems undergo, manifest themselves as task execution 
time changes. A brief discussion of these changes follows. 

Note that, the task parameters, deadline and periodicity are dictated 
primarily by the environment. The arrival time of a task is governed by the 
environment and the inter-dependence between the tasks. The execution time 
of a task on the other hand is governed among other things by: (i) the pro- 
gramming language chosen, (ii) the compiler, (iii) the operating system, and 
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(iv) the processor architecture (e.g., pipeline, cache). Therefore, finding the 
execution times of tasks is complex and involved [31, 23, 1], In most cases it 
is almost impossible to compute a deterministic measure of the execution time 
of a task. Most research efforts use the worst-case task execution time and not 
the mean execution time. While this choice can be justified by the fact that 
the analysis is based on the worst-case scenario, it nevertheless results in an 
over-design of the system. Also, this assumption can result in poor resource 
utilization. 

Using mean task execution times in the computation does reduce the 
pessimism but unfortunately we could have cases where the guarantees provided 
by the schedulability analysis could be invalid (The number of such cases being 
determined directly by the variance in the computed mean execution time). 
Therefore, it is necessary to accommodate the variance information along with 
the mean (for task execution times). For example, if the mean execution time 
of a task is e and the variance of this mean is cr then it implies that the actual 
execution time is most likely to lie in the interval (e-<r, e + cr). Schedulability 
analysis done using the mean execution time will remain valid even when the 
actual execution time falls between (e - <r, e). However, the same does not 
hold for the interval (e, e + cr). Assuming, the variance is expressed in terms 
of the mean (which is quite a common practice), we can represent cr as fac x e, 
where fac is a constant. If we can extend the analysis done by using the mean 
execution time to accommodate the possibility of the execution time being 
scaled by a factor sf then, it can be seen that this is equivalent to: allowing a 
variance of fac x e. Where, sf = 1 4- fac. 

As a system evolves the functionalities of tasks expand, reflecting in 
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terms of improvement in the data handling of tasks. For example, as an air 
traffic control system adapts to new traffic (say from monitoring 8 flights to 12 
flights) though the tasks themselves (their code that is) might not change the 
data handled by the tasks can change, resulting in an increase in the execution 
times of the tasks. This increase does affect the schedulability guarantees made 
using the previous execution times. Therefore, what we are interested in is. 
finding a factor sf by which the execution times can be scaled (capturing the 
data handling change) without invalidating the schedulability guarantees. 

A more direct scenario that affects the completion time computation 
occurs when the target platform changes. Any analysis performed (to guaran- 
tee performance) assuming particular values of task execution times becomes 
invalid once the target platform changes. For example, a faster processor could 
result in a lower execution time (not invalidating the analysis), but a slower 
processor would surely have an adverse affect on the schedulability analysis. As 
a system evolves, though in general the overall system is likely to improve, the 
performance of individual components (some processors for example) might not 
always improve. Another instance where a target platform is in general slower, 
arises in the case of prototype building and testing [51]. 

A last case where we observe the need to do schedulability analysis for 
at least two target platforms arises in the area of fault tolerance. It is common 
practice to provide fault-tolerant operation by the use of redundant components 
(often at least one secondary component). In general, secondary components 
provide only a minimal functionality (sufficient to keep the system operational 
till the primary is fixed) and therefore tend to be slower. Any schedulability 
analysis guarantees provided with the primary component as the target will be 
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invalid once the system falls back onto the secondary. 

From the above discussion we note that, what we need is a measure 
(will be referred to as the scaling factor for obvious reasons) that in some sense 
qualifies the schedulability analysis. Provided the task execution times (as a 
result of the changes described above) satisfy a bound dictated by this measure 
the schedulability analysis remains valid. 

We now discuss the underlying theory derived from past results in the 
area of real-time systems that is used in this study. 

3.1 Scheduling Theory 

Research in schedulability analysis has been focused mainly on uniprocessor 
systems. In recent years the original fixed priority analysis [24] has been consid- 
erably extended, relaxing many of the assumptions of the original computation 
model. Lehoczky et. aV s [20] efforts to find the worst-case timing behavior of 
rate-monotonic tasks was the first in this direction. They have subsequently 
extended this result further, to accommodate any fixed priority task assign- 
ment [19]. In this thesis we make extensive use of this result. 

The following, is a brief discussion of scheduling under different assump- 
tions about the environment and tasks. A good source of related discussion 
can be found in [48] and [40]. 

3.1.1 Static versus Dynamic Scheduling 

Static scheduling mechanisms assume complete a priori knowledge about the 
task characteristics including inter-task dependencies. Such assumptions are 


29 


valid in many of today’s practical real-time systems [39]. For example, real- 
time control of a process control application might have a fixed set of sensors 
and actuators, and a well defined environment whose processing requirements 
are all known a priori. The operation of the static scheduling algorithm in such 
a system involves producing a fixed schedule for what is called a hyperperiod. 
The fixed schedule repeats every hyperperiod [48]. For example if the arrival 
times of all tasks in a task-set are 0 then the hyperperiod is given by the least 
common multiple (LCM) of the task periods. A static scheduling algorithm 
assigns a fixed priority to each task that remains unchanged for the lifetime of 
the task. 

It has been shown by Liu and Layland in their very well known pa- 
per [24] that the rate monotonic priority assignment (RMS) guarantees the 
schedulability of a task-set (of n tasks), if the utilization of the task-set is less 
than or equal to n( 2 1/<n — 1). For large n this bound tends to 0.693. Further, 
the RMS was shown to be an optimal static fixed priority assignment when the 
deadlines of tasks coincide with their periods. Other significant results in this 
direction were, Leung’s [21, 22] formulation of an alternative (static fixed) pri- 
ority assignment to accommodate tasks whose deadlines are less than or equal 
to their periodicities. Audsley et. al. [2] allowed the addition of guaranteed 
sporadic tasks and Tindell et. al. and Locke [26, 27] considered the possibility 
of tasks having a release jitter. 

If a real-time system operates in a dynamic environment where it is 
impractical to assume complete knowledge of the processing requirements of 
tasks (and their interactions) we use a dynamic scheduling mechanism. In such 
a case the chosen dynamic scheduling algorithm is analyzed off-line using the 
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expected requirements of the dynamic environment. The same algorithm is 
then used at run-time with the assumption that the run-time behavior of the 
system does not depart markedly from the expected behavior for which the 
scheduling mechanism was tested. A static or dynamic scheduling algorithm 
can be applied in either of the cases, viz., the environment is known or changes 
dynamically. However, what distinguishes the two is the performance guaran- 
tees that can be made about the scheduling mechanism. For example, if the 
assumption of complete a priori knowledge about the system does not hold 
then, while a static scheduling algorithm can be used but it will not be able to 
make any schedulability guarantees. 

The earliest deadline first (EDF) scheduling mechanism [24] is the most 
widely used dynamic scheduling mechanism. EDF runs that task among the 
task-set that is ready to run and is closest to its deadline. Therefore, as a 
task nears its deadline its priority relative to other tasks increases. The EDF 
scheduler was shown to be an optimal dynamic scheduler in the sense that, if 
there exists a scheduler that can guarantee that all the tasks would meet their 
deadlines then, so will EDF. A drawback of the EDF scheduler is that in its 
comparison of tasks, T,, Tj, with deadlines, dj, dj, there is no regard for their 
execution times, ej, ej. Therefore, even if the two tasks’ deadlines differ by a 
small amount ( dj — dj = +e), dj will be chosen to run instead of dj even if 
their execution times differ by a large amount (e, << ej). The least laxity first 
(LLF) scheduler [29] uses a different basis for priority assignment that partly 
answers the need to accommodate the execution times of tasks. The laxity of 
a task, T{ is the difference (dj — ej), between the deadline and the execution 
time of a task. It essentially captures the room for meeting the deadline of a 
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task. LLF scheduler has also been shown to be an optimal dynamic scheduler. 

In summary, the choice of a particular scheduling mechanism is governed 
by such considerations as: (i) The assumptions that can be made about the 
environment (static vs. dynamic), (ii) the guarantees provided by the sched- 
uler being considered, (iii) the cost in terms of computational overhead of the 
scheduler and (iv) the constraints on the task characteristics (e.g., deadline < 
period of tasks). 

3.1.2 Relationship between deadline and period 

The classical scheduling result by Liu and Layland [24] is built on the assump- 
tion that the deadlines of tasks are equal to the periods of tasks. In other 
words, an instance of a task is required to be completed before its next in- 
stance is ready. As already mentioned, the rate-monotonic priority assignment 
(RMS) gives an optimal fixed priority scheduling mechanism for this scenario. 

However, if the deadlines of tasks are allowed to be less than or equal 
to their periods (i.e., d{ < p, V7)) then the optimality of RMS does not hold. 
As shown by Leung and Whitehead in [22], the deadline monotonic scheduling 
(DMS) mechanism is an optimal for this scenario. The DMS assigns the highest 
priority to the task with the shortest deadline. This DMS scheme is optimal in 
the sense that if any fixed priority scheme can schedule a task-set then so can 
the DMS scheme. One should not confuse the deadline monotonic scheduler 
with the EDF which is a dynamic scheduling mechanism where a task’s assigned 
priority can change dynamically. A special case of this scenario occurs when 
the deadlines of tasks are a constant factor of their periods. In other words, 
VT, , d, = k x pi, where k < 1. Note that both RMS and DMS would end up 
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being the same in this case. 

The third scenario occurs less commonly in real-time applications (more 
common in imprecise computation [25, 36, 37]), where the deadlines of tasks 
can be beyond the end of their periods. This scenario was first studied by 
Lehoczky [20], where he considered the possibility of k (in the formulation of 
the previous paragraph) being greater than 1. He showed that for a value of 
k = 2 the utilization bound of RMS increases from 0.693 to 0.811. He reported 
simulation studies that show a more promising (close to 1.000) increase in the 
achievable utilization. 

3.1.3 Precedence Constraints and Resource Sharing 

An inherent characteristic that governs current complex real-time systems is 
the cooperation of tasks to achieve the goal of an application. Such cooperation 
can be captured by various types of communication semantics. Depending upon 
the chosen semantics, tasks experience precedence constraints or blocking or 
both. Blocking occurs due to the use of a synchronization mechanism (like 
priority inheritance protocol [33]) to regulated resource sharing. Similarly the 
use of critical sections to achieve concurrency control (Sha et. al. [34]) can 
result in blocking. An alternative to using a concurrency control mechanism 
for regulating resource accesses is to impose strict order on these accesses. 
Such an order can be captured by imposing precedence constraints on tasks 
that share the same resource. As was shown by Tindell et. al. in [45] and will 
be explained in more detail in chapter 5 of this thesis, these two scenarios can 
be captured by considering tasks to have arrival time characteristic in addition 
to execution time, period and deadline. 


3.2 Uniprocessor Schedulability 

Most schedulability results [24, 19, 46] are based on the critical instant argu- 
ment, which defines a worst-case condition for a task. As noted before, worst- 
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case completion time computation is the crux of schedulability analysis. The 
critical instant argument gives us a situation under which a task will undergo 
its worst possible completion: 

Lemma 3.2.1 The worst-case completion time for task 7 1 , occurs when it ar- 
rives at a critical instant, a\ = ... = a, = 0. 

This lemma tells us that any instance of a task that arrives at a point 
in time when all higher priority tasks also arrive suffers the worst completion 
time. We still have to compute this completion time. The following equation 
gives a mechanism for this computation: 

X 

W x is = the smallest X for which( ^ e 7 f — ] + e,) < X 

j = ltoi — 1 

The above equation can be viewed in terms of demand and supply. The 
term H J=Uo ,_i captures the demand for processor time from all instances 

of tasks with priority higher than i over X units of time. Therefore, the fraction 
in the above formula gives the ratio of the demand to the supply. The shortest 
supply X for which the demand is met, i.e., supply > demand , gives the 
completion time of the task = W x . Further, if this value W, is less than or 
equal to the deadline of the task ( D ,), then the task meets its deadline. 



3.3 Other Relevant Work 


The area of end-to-end scheduling is a relatively new are in real-time systems. 
Prominent work in this area has been reported by Bettati in his thesis [4], As 
he showed in [4], the problem of finding an optimal scheduler for scheduling 
end-to-end tasks is NP-complete [13]. To this end, he proposed and analyzed 
heuristic approaches to solving this problem. The schedulability test he uses to 
test his heuristic schedulers is based on the critical instant argument. As was 
discussed before, this results in a pessimistic evaluation of the scheduler. It is 
therefore possible that he rejected heuristics that did not perform well under the 
pessimistic test but would in fact have been able to guarantee schedulability. 

Other ongoing research on this problem was reported by Etamadi in [7]. 
He proposes to enhance the analyzability of end-to-end systems without mak- 
ing constraining assumptions that restrict resource utilization. Further, he pro- 
poses building robust application models that would allow enhancements like 
synchronization, communication. Related work can also be found in [14, 30]. 

Finally, on the problem of admission control of RT channels [28, 9]. The 
Tenet group’s Ferrari et. al. were the first to deal with this problem extensively. 
The principle they followed [8, 9] in the design of an admission control scheme 
is based on verifying, whether the resources available on the path of the newly 
requested RT channel are sufficient even in the worst possible case, to 

1. provide the new RT channel with the QoS it needs and, 

2. allow the guarantees offered to all the existing RT channels to continue 
being satisfied. 
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The above verification depends upon the kinds of QoS parameters al- 
lowed. The most important QoS parameter of concern to real-time system 
designers is meeting a latency bound (deadline). We restrict our interest to 
this parameter. There are two tests that are relevant in this context: 

• Schedulability Test: Does the addition of the new channel to the already 
established channels using this link cause either the new channel or one 
of the already established channels to miss their deadline? 

• Buffer Space Test: Is the available buffer space at the link sufficient to 
allow the messages of the new channel to be stored for a length of time 
equal to the delay faced by the channel at this link? 

Different approaches to the admission control problem (in real-time sys- 
tems) will differ in the way the above two questions are answered. Therefore, a 
study in admission control reduces to the study of these tests. The buffer space 
test has been successfully addressed by the Tenet group [9]. We concentrate 
mainly on the schedulability test because it is our belief that there is room for 
improvement here. In particular, there are many situations that have not been 
considered in this context. 



Chapter 4 


Problem Statement and Description 

4.1 Scalability of Uniprocessor Systems 

The uniprocessor scalability problem can be formally defined as follows: 

Problem Definition 4.1.1 Given a task-set T consisting of n tasks , and a 
subset S o/T . Find the maximum common scaling factor by which the execution 
times of each of the tasks in the subset S can be scaled, without affecting the 
schedulability of the task-set T. 

As described in the previous chapter, the schedulability of tasks running 
on a uniprocessor can be determined by lehoczky’s [19] schedulability test. The 
scalability problem now involves extending this test to compute the scaling 
factor. 


4.2 Scalability of End-to-End Systems 

The problem of interest here is the “Scalability of task-sets in end-to-end real- 
time systems”. The problem can be looked at from two different viewpoints: 
(i) The first viewpoint stems from assuming the scaling to occur as a result 
of a change in one or some of the components in the system; (ii) The second 
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viewpoint stems from assuming the scaling to occur as a result of a change in 
the functionality of some or all of the sub-tasks in the system. 

4.2.1 Component Change 

A change in a component Rj can result in a gain or a loss in the speed of 
processing for the sub-tasks running on it. Clearly, if there is a gain in speed 
of a component then this will not have any adverse affect on the completion 
times of sub-tasks running on it. However, if the component is replaced by a 
slower one then it will affect the completion times and hence the schedulability 
of the sub-tasks running on it. The problem of interest therefore is, to find the 
maximum factor by which all the sub-tasks on a particular component Rr can 
be scaled such that the schedulability of the task-set (comprising all n tasks 
that is) is unaffected. 

In the following formulation we assume that a single component is un- 
dergoing a change. We can however, generalize it to a sub-set of components. 
The problem of scaling occurring as a result of a component change can now 
be formally posed as: 

Problem Definition 4.2.1 Given a task-set T ofn end-to-end tasks executing 
in a system of m, (m > 1) components , find the optimal scaling factor l/sfc 
(corresponding to a maximum s fc) with which the processing speed of a given 
component r can be scaled (down), without affecting the schedulability of the 

task-set. 

In other words, we are interested in the maximal component change 
the task-set can survive. The reason for representing the scaling factor as a 
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reciprocal will become obvious once we realize that a lowering in processing 
speed of a component will reflect as an increase in the execution times of sub- 
tasks running on the component. For example, if the speed of the component 
is S (instructions per unit time) then an execution time requirement of a sub- 
task T t k being (time units) implies that the number of instructions that the 
sub-task requires to execute are S x e ik . If the processing speed is scaled down 
by I fsfc (implying that sfc> 1) then, we have the new speed S' = 5 x 1/s fc. 
Therefore, the amount of time it would take to execute S x instructions* is 
given by: 

S x e, fc 

S' 

S x ejk 
S x I/s/c 
s/c x e ik 

In this formulation, we assume that all sub-tasks that execute on com- 
ponent r will be equally affected. That is for all sub-tasks T jr (1 < j < n) 
running on component r their execution times as a result of the change would 
become sfc x e^ r . The next perspective to the scaling problem however, allows 
for the possibility that only a subset of the sub-tasks running on a component 
are affected as opposed to all sub-tasks being affected. 

4.2.2 Task Changes 

As opposed to a change in one or more components, we can envision one or 
more sub-tasks being affected by a change. For example as a system evolves, 

1 Assuming that a change in the component is such that the same code is able to run on 
the new component 
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to encompass more functionality, some of the sub-tasks (their code that is) 
need to be modified (enhanced), resulting in an increase in their execution 
times. Alternatively, enhancements could come in the form of increased data 
handling, manifesting as an increase in the execution times of tasks (as before 
we do not consider decreases because they do not violate prior schedulability 
guarantees). The problem of scaling occurring as a result of task changes can 
now be formally posed as: 

Problem Definition 4.2.2 Given a task-set T of n end-to-end tasks executing 
in a system of m, (m > 1) components, find the maximum scaling factor, sft 
with which a subset of the sub-tasks (say S : {T^, where 1 < i < n; 1 < 
k < m}) execution times can be scaled, so that the task-set T ’s schedulability 
remains unaffected. 

As it will be clear from the following discussion, solving the end-to- 
end schedulability problem can be reduced to solving m independent (deemed 
independent by an important transformation to be described later) single com- 
ponent schedulability problems. In other words, solving the above formulated 
scalability problem for a subset 5 will become equivalent to solving m single 
component scalability problems on each of the subsets S\, Si, . . . , S m . A subset 
S T contains all sub-tasks T tr , (Vi) belonging to S. If for a particular component 
r, there are no sub-tasks T tr (Vi) in 5 then we set the corresponding set S r = 0 
(null set). 
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We can observe one step that is common to the above two formulations, viz., 
determining the schedulability of the given task-set T. This is the initial step 
to be done in solving both these problems. Note that, if a task-set T is un- 
schedulable to start with then, any adverse change either to a component or 
to a subset of the sub-tasks is only bound to make the situation worse. The 
problem of interest can therefore be posed as: 

Problem Definition 4.2.3 Given a task-set T ofn end-to-end tasks executing 
in a system of m components, find if the task-set is schedulable. 

In order to find the schedulability of end-to-end task-set, we have to find 
if each end-to-end task in turn will be schedulable, i.e., meet its deadline when 
the individual sub-tasks compete for processing on their respective components. 
Therefore, for each task we have to find its worst-case completion time which 
can then be compared against its deadline. The worst-case completion time of a 
task Ti can be computed by assuming that all its sub-tasks simultaneously suffer 
their worst-case completions. The worst-case completion time of the task (Ti), 
is then given by the sum of the worst-case completion times of the individual 
sub-tasks (T.jt). For a given sub-task T tk , executing on the component R k , the 
information we need to find its worst-case completion time is: 

• The arrival time of all sub-tasks T jk ( j < i) 2 , which are of higher priority 
than T xk and are running on the same component, R k . 

2 Unless otherwise specified, the arrival time of a sub-task T ik implies the arrival of its 
first instance 


• The periodicity of all sub-tasks T 3 k (j < which are of higher priority 
than T x k and are running on the same component 7?^. 

Notice that when, i = n we have to find the arrival time and periodici- 
ties of all sub-tasks in the system to determine the schedulability of the task T n . 
Therefore, we need a mechanism by which we can derive these two parameters 
(since these are not given a priori). Note that, only the first sub-task of any 
task is truly periodic. The arrivals of the consecutive instances of any sub-task 
T x k, (1 < i < n; 1 < k < m) are dictated by the completion times of the sub- 
task preceding it, i.e., T x k-\- These completions are obviously non-periodic 
and so are the arrivals of sub-task 7^. We however can impose a periodicity 
on these sub-tasks by a proper justification. The phase adjustment mecha- 
nism [51], is one such mechanism that derives sub-task arrival times and also 
their periodicities. The term phase here is used to denote arrival time. 

Imposing a period on the arrivals (of consecutive instances that is) of a 
sub-task Tik ( l < k < m), implies that, even if the preceding sub-task T x% k-\ 
does finish at a particular time 3 (say F ty k-\), the sub-task T t * will not be ready 
immediately. A finite amount of time (say W lt k- i — F{ t k- 1 ) 4 has to elapse before 
the sub-task T x k is ready to execute. It is necessary to limit this finite amount 
of wait time in the sense that, if it is too large then it could hurt the utilization 
of the component /?*. This is due to the fact that, while the sub-task is being 
intentionally delayed, the component Rk could be idle. On the other hand 
this delay must be large enough to be able to accommodate all possible finish 

3 All references to time are relative to t = 0, unless otherwise specified 
4 Here. W l k - 1 is a constant for the task T.jt-i; therefore, the delay is a variable for each 
instance of Ti i 
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times (of its various instances) of task Ti y k-i- Clearly therefore, in the limiting 
condition (delay = 0) W^k - 1 must be given by the worst-case completion time 
of the sub-task Ti tk -\- 

An effect of this adjustment is that a sub-task T,* will always be ready 
(or arrive) after a constant amount of time from the arrival of the preceding 
sub-task T x< k-\- Therefore, knowing the arrival time of the sub-task Tii, we can 
find the arrival of the sub-task T & , knowing which we can find the arrival of 
T t3 and so on. It should be clear to the reader that the above adjustment also 
allows all sub-tasks belonging to a task to inherit its period. 

What the above adjustment has afforded us is, the ability to treat 
each of the components independently, provided we are able to find the terms 
W tk (Vi, k ). Observe that we have all the information about sub-tasks T iX (1 < 
i < u), running on the first component, R\ (That is, we have their arrival times, 
periods and execution times). Now the problem we wish to solve is finding the 
worst-case completion times of these tasks. Once we find these worst-case 
completion times we have all the information about sub-tasks Tu (1 < i < n), 
running on the second component, R 2 and so on. The problem of interest can 
therefore be formally posed as: 

Problem Definition 4.2.4 Given a task-set T of n tasks executing on a single 
component, find the worst-case completion times of all tasks in the task-set. 

Observe that this problem is similar in sense to the schedulability prob- 
lem solved by Lehoczky [19] (refer to Chapter 3). However, while his solution 
using the critical instant argument can be used in the context of uniprocessor 



systems, we cannot use it here (in the context of end-to-end systems that is). 
Finding a solution to this problem is one of the results of this thesis. 
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Now that we described a mechanism to test whether a given task-set is 
schedulable, we have answered the question of whether there exists a scaling 
factor as defined by the two problems, 4.2.1 and 4.2.2. Clearly, if the tasks are 
so stringent that any increase in the execution times of the sub-tasks cannot 
be tolerated, then the scaling factors sfc (as defined in problem 4.2.1) and sft 
(as defined in problem 4.2.2) will both be equal to 1.0. 

The end-to-end schedulability problem has been reduced to m single 
component worst-case completion time computation problems and not m single 
component schedulability problems. Therefore, we cannot talk about extending 
a single component’s schedulability, unless we derive the sub-task deadlines. A 
major research issue in end-to-end scheduling has been the derivation of sub- 
task deadlines. Given an end-to-end task’s deadline the problem of finding an 
optimal 5 division of this deadline among the sub-tasks is intractable [15] (NP- 
complete [12]). This result has prompted a heuristic approach [4, 15, 30], two 
such heuristics being: (i) divide the task’s slack 6 equally among the sub-tasks; 
(ii) divide the task’s slack among its sub-tasks in a weighted proportion of their 
execution times. 

The above two heuristics vary mainly in their sensitivity to the execution 
times of tasks. For example, the second heuristic is built on the assumption 
that the shorter a task’s execution time requirement, the more likely it will have 

5 In the sense that, if there exists a division that would help the task meet its deadline 
then the mechanism should find it 

6 The slack of a task is given by the difference between its deadline and its execution time 
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its requirement met and therefore the lower is the slack assigned to it. The 
first heuristic is built on the assumption that the priority inherited by a sub- 
task has a greater impact on its ability to meet its execution time requirement 
than its execution time itself. Thus the slack is divided equally among all sub- 
tasks. This allows us to reduce the end-to-end scalability problem to m single 
component scalability problems. 

Now, finding the common scaling factor is a simple matter of finding 
the minimum of the m scaling factors (each corresponding to one component). 
The problem of interest therefore is the single component scalability problem, 
which can be formally defined as follows: 

Problem Definition 4.2.5 Given a schtdulable task-set T of n tasks execut- 
ing on a single component and a subset S ofT, find the maximum scaling factor 
sf with which all tasks in S can be scaled without violating the schedulability 
of any of the tasks in T . 

Now, we can observe that solving the two problems 4.2.1 and 4.2.2 
amount respectively to: 

• Solving the single component scalability problem (4.2.5) with S = T. 

• Solving the m single component scalability problems and taking the min- 
imum among these scaling factors. 

We can now summarize this discussion on end-to-end scalability bv not- 
ing that, solving this problem entails finding solutions to the two problems, 
4.2.4 and 4.2.5. 
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4.3 Admission Control of RT Channels 

The problem of admission control of real-time (RT) channels was first inves- 
tigated by Ferrari et. al. [9] at the Tenet group. Admission control is the 
mechanism by which multiple real-time connections can simultaneously share 
the resources of a packet switching network without resulting in congestion. 
Further, the connections are guaranteed a particular quality of service (QoS) 
that is initially (at connection set up) agreed upon. Admission control comes 
into play when a new RT channel is being requested. An RT channel (or 
a connection request) is accompanied with a QoS list that describes the re- 
quirements of this connection. Popular QoS requirements in the literature of 
distributed real-time systems are - throughput, latency (or deadline), packet 
loss tolerance [28, 10, 35] etc. 

The mechanism used to determine the admissibility of a real-time chan- 
nel involves verifying at each intermediate link (along the path) in turn whether 
the RT channel’s QoS requirements can be guaranteed. If a channel’s require- 
ments can be met at each of the intermediate links then we can accept the 
channel. If however, the channel’s requirements cannot be met at any of the 
intermediate link then we can reject the channel. In fact the first such link that 
deems the channel inadmissible is sufficient to confirm that the channel would 
not be admissible. 

In order to test whether a channel’s requirements will be met at an inter- 
mediate link we have to know its deadline and its period at that link. Finding 
the period is straightforward according to the phase adjustment mechanism. 
However we do have to derive the deadline of the RT channel at intermediate 
links. Since the service time of the channel on each of the links is the same 
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one way to derive the deadlines would be to divide the slack of the RT chan- 
nel equally among the intermediate links. However, if one wishes, one can use 
a more sophisticated heuristic [15, 4] to derive these deadlines. This reduces 
the problem of finding the admissibility of an RT channel to be equivalent to 
solving the admissibility at each of the intermediate link. From here onwards 
when we refer to the admissibility of an RT channel we mean its admissibility 
at an intermediate link. 

Now, the question that admission control has to answer when accepting 
a new connection can be broadly phrased as: 

Problem Definition 4.3.1 Given the QoS requirements of a new RT channel 
is it possible to accept this channel without violating the QoS guarantees made 
to RT channels that have already been accepted? 

To summarize this chapter, we have defined four problems of interest: 

• The uniprocessor scalability problem (4.1.1), 

• The single component schedulability problem (4.2.4), 

• The single component scalability problem (4.2.5), and 

• The problem of admission control of RT channels (4.3.1). 

The next chapter discusses the first of these problems. Note that, the third 
problem in the above list is different from the first in that, it involves tasks 
whose arrival times cannot be assumed to be zero (as in the critical instant 
assumption). 



Chapter 5 


Scalability in Uni-processor Environments 


As discussed in Chapter 1, a host of schedulability related issues translate into 
a more general problem called the scaling problem. Observe that the scaling 
factor as defined in the problem statement attempts to capture a common factor 
by which a sub-set of tasks belonging to a task-set can be scaled together. In 
our first attempt at this problem we made an assumption that the sub-set S is 
the same as the task-set T. That is, we were interested in scaling the complete 
task-set as opposed to a sub-set of tasks. A solution to this problem can be 
found in [52]. The following discussion however considers the general scaling 
problem as stated in Problem 4.1. The model assumed is the uniprocessor 
model described in chapter 2. We repeat the problem statement here and 
give a discussion about the possible approaches to the solution followed by the 
details of the solution approach we have taken. 

5.1 Problem Statement 

• Given a task-set T consisting of n tasks, and a subset S of T . Find 
the maximum common scaling factor by which the execution times of 
each of the tasks in the subset S can be scaled, without affecting the 
schedulability of the task-set T. 
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The particulars about the scheduling algorithm used to schedule these 
tasks have not been specified in order to keep the problem general. The choice 
of scheduler can be either a dynamic scheduler (like earliest deadline first ) or a 
fixed priority static scheduling algorithm. If the chosen scheduler is the latter 
then the tasks are assumed to be numbered (decreasing order) according to 
their priorities as dictated by the scheduler. The term, scaling factor is used 
to refer to a scale up in the execution times and not a scale down. It can be 
shown that if the execution time of a task is reduced then the schedulability of 
the task (and other lower tasks) will remain unaffected. 

The use of the term, “maximum” needs some explanation here. The 
scaling factor we desire is one that cannot be improved upon. In other words, 
given that sf is the maximal scaling factor and e is an infinitesimally small 
quantity. Using sf to scale the tasks in S would not affect the schedulability 
of the task set whereas using sf + e as the scaling factor results in at least one 
of the tasks in T being unschedulable. 

5.2 Discussion of Possible Solution Approaches 

We concern ourselves mainly with a static fixed priority scheduling mechanisms 
because the above problem has a rather trivial solution when we assume a 
dynamic preemptive scheduling algorithm (say EDF). It is possible to find a 
feasible schedule using a dynamic scheduling mechanism provided the following 
condition holds for the utilization [24]: 


u=± - < 1 

vter Pi 
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If the utilization of the task-set is greater than 1. then clearly the task- 
set is not schedulable by any dynamic scheduling mechanism and further the 
question of scaling the tasks is not relevant anymore. The above condition is 
both a necessary and sufficient condition for EDF to be able to guarantee the 
schedulability of the task-set. Therefore, meeting the above condition ensures 
the existence of a scaling factor. Now, given such a task-set we can scale the 
tasks in the sub-set such that the new utilization U' — 1. 

v = ( E 3j ^) + ( T. 

\Vj 6 5 Pi ) \V, € (T- 5 ) Pi ) 

= */«,*( E -)+"-( £ -) 

Wts Pi) \*fts Pi) 

= {*/«*/ - !) x ( E rH + u 

W € 5 Pi) 


The scaling factor of interest therefore is when U' = l, given by: 


r 1 -U 

Sfedj = “= «7 + 1 

Vj 6 S Pi 


This factor is not valid in the case of static fixed priority preemptive 
scheduling algorithms because the above condition on utilization (i.e., U < 
1) does not necessarily guarantee the existence of a fixed priority scheduling 
algorithm. A similar bound does exist for the rate monotonic scheduler (RMS: a 
fixed priority scheduling mechanism), under the assumption that the deadlines 
are equal to periods: n(2 l/n - 1). The rate monotonic priority assignment is 
known to be optimal in this case [20]. Further, the total utilization of the 
task-set being less than or equal to n(2 l/n - l) is a sufficient (not necessary) 



condition for optimality. In other words the above condition guarantees that a 
rate monotonic priority assignment will result in the task-set being schedulable. 
Therefore, one can say that a scaling factor sf rrn3 (following the same derivation 
as above but replacing the utilization bound n( 2 l/n - 1) for 1) given by the 
following equation does not violate the schedulability of the task-set. 


sfrms 
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The above computation of the scaling factor does give us a valid factor 
in the sense that using this factor to scale tasks does not violate the schedula- 
bility of the task-set. However, it is not necessarily optimal in the sense that 
the resulting utilization bound is not a tight bound. In order to understand 
why this bound is not tight one has to look more carefully at the meaning of the 
schedulability bound, n( 2 I ^ n — 1). This bound is only a sufficient and not a nec- 
essary condition for the task-set to be schedulable by the RMS mechanism [20]. 
Therefore it is possible that a task-set does not meet this schedulability bound 
and yet is schedulable by the RMS mechanism. Therefore we observe that a 
more precise analysis is necessary to get the maximal scaling factor. 


A second observation one has to make about the above scaling factor 
computation is that, the computation derives its validity from the fact that the 
rate monotonic priority assignment is optimal when deadlines and periods of 
tasks coincide. If this condition (deadlines equal periods) does not hold then, 
we can no longer use the above result. If the deadlines of tasks are known to be 
less than their periods, then the deadline monotonic priority assignment (DMS) 
is known to be optimal [22]. However, there is no known sufficient condition 


on the total utilization. Therefore, in order to compute the scaling factor we 
have to do a more precise analysis of the task-set. 

As a special case of the scaling problem, if the sub-set S is same as T 
then the scaling factor would be a simple reciprocal of the utilization in the 
case of EDF (i.e., sf^/ = jj ) . Similarly, in the case of RMS, the scaling factor 
using the approach above would be, sf rm3 = n ' 2 'jj (this is not optimal, as 
already discussed above). 

In the following, we give the algorithm to find the maximal scaling 
factor when an arbitrary (RMS and DMS being two instances) fixed priority 
assignment is used. Before the details of the mechanism are presented we would 
like to intuitively motivate the idea behind it. We consider the case of scaling 
all tasks to present the motivation. Since we are interested in the common 
scaling factor, one approach would be to consider a successive approximation 
technique as taken by [6]. Incremental factors are used to scale tasks and 
perform a schedulability analysis to confirm if the increment is acceptable. 
Clearly, such a technique would be expensive. 

An alternative approach would be to incorporate the scaling factor com- 
putation into the schedulability test. This is the approach we have taken. The 
schedulability test we use is the one proposed by Lehoczky in (refer to Chapter 
2). The idea behind Lehoczky’s schedulability test is to ascertain the schedula- 
bility of each task in turn starting from the highest priority task. The schedu- 
lability of each task involves considering all tasks that are of higher priority 
than itself. Therefore, the schedulability test of a task T, can be interpreted as 
follows: To ascertain whether task T, will meet its deadline while continuing to 
honor the timing requirements of all higher priority tasks. Note that the test 



52 


does not consider whether the higher priority task meets its deadline. It only 
makes sure that any higher priority task will not wait for the processor while a 
lower priority task is using it. In other words, it ensures that in every p } ( j < i) 
time units the task corresponding task Tj would get e } units of the processor’s 
time. It is possible for example that, a higher priority task Tj gets its last unit 
of required execution time between d 3 and pj (note dj < Pj l < j < ra), thus 
meeting its demand 1 but not its deadline. 

On the same lines our approach to finding the scaling factor attempts to 
find the scaling factor for each task in turn starting from the highest priority 
task. The scaling factor (s/*) obtained with respect to a task T, therefore 
guarantees that the task Tj would meet its deadline continuing to honor the 
scaled (scaled by s/‘) requirements of all higher priority tasks. In other words, 
sf' is the factor with which the execution times of all tasks with priority greater 
than Tj and including Tj can be scaled without Tj missing its deadline even after 
accommodating all the scaled higher priority tasks. The required scaling is then 
the minimum of all computed scaling factors s/j. A more detailed treatment 
of the solution follows. 

5.3 Details of the Approach Taken 

An analogy can be drawn between the computation of the scaling factor s f* and 
assessing the schedulability of the task 7j. In order to assess the schedulability 
of task T, we compute the worst-case completion time of task Tj and compare it 
against its deadline. This computation takes into account the execution time 


'It will not wait for the processor while a lower priority task is using it 
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demands of higher priority tasks (but is independent of the higher priority 
tasks’ ability to meet their deadlines). Similarly in the computation of the 
scaling factor with respect to task Ti, we only account for the execution time 
(scaled) demands of the higher priority tasks and not the ability of these tasks 
to meet their deadlines. 

We find such scaling factors for all tasks and the required scaling factor 
is the minimum among these, i.e., sf = Minimum(sf'). Note that each of the 
scaling factors sf' only considers the schedulability of task 7i and any scaling 
factor that is less than sf' will continue to guarantee its schedulability. Since 
we are interested in a common scaling factor, the lowest of the scaling factors 
sf' h < i < n (The index h is defined below). In the following paragraphs, 
we present the details of the technique for the general scaling problem and a 
proof of its operation. 

We make use of the schedulability test described in [19, 6] to find the 
worst-case response times of tasks. 

Note that in the previous section we assumed that T = S 2 in order to 
simplify the explanation of the solution. In this context we gave a definition 
of s f' that needs a slight refinement to adapt to the case that the set 5 is not 
necessarily equal to T. The scaling factor s /' is the factor with which the tasks 
in the set S with priorities higher than Ti can be scaled without affecting T, s 
schedulability, while continuing to honor the demands of all tasks with priority 
higher than T,. The requirements of higher priority tasks include both: (i) 
the requirements of higher priority tasks that are not included in 5 and (ii) 


2 We assume that the tasks in 5 are sorted in a non-increasing order of their priority 



the scaled (scaled by sf' that is) requirements of higher priority tasks that are 
included in 5. There are two important observations to be made: 

• In the computation of the scaling factor sf 1 the task T, is not necessarily 
a member of S. This is because there are tasks in T that do not belong 
to S whose schedulability could be affected by the scaling of tasks in S. 
And we cannot ignore them in computing the desired scaling factor. 

• The number of scaling factors to be computed is equal to n — h. The 
number of tasks in T of priority less than the highest priority task in S . 
Clearly from the definition of sf* in the above paragraph, we see that for 
all tasks T, whose priority is greater than the any in S, sf ' is undefined. 

The given sub-set S is assumed to be sorted by the decreasing order of 
priorities. Let be the highest priority task (first task) in S 3 . For each task 
Tj where h < i < n (starting from i — h and counting up), we find the scaling 
factor by which all tasks in S whose index is < i can be scaled, while continuing 
to maintain Tf s schedulability (i.e., meeting its deadline and the demands of 
all tasks with priority higher than T, are honored). 

Since we make the critical instant assumption, only the first task in- 
stance of any task T x needs to be considered for its schedulability [19]. Note 
that only higher priority tasks affect the schedulability of a task, because lower 
priority tasks will be preempted. We consider the execution profile of task 
T,(i > h) along with all higher priority tasks Tj where j < i. In Figure 1, the 
first continuous block (no idle time in between) of used time is represented as 

3 Task Th is the highest priority task that needs to be scaled. 
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U\ . The notation U\ is also used to represent the length of this block. The j th 
such used time block is represented as Uj. Further, U h i and U h R represent the 
left and right boundaries of the block Uj (i.e., Uj = U J: r — U 3 } l) respectively, 
relative to the start time of consideration (i.e., U\ t L, which can be assumed 
without loss of generality to be zero). The first task instance of 7i (refer to 
Figure 5.1) completes at a point U\ units of time after it has arrived, with 
all higher priority tasks also arriving at U the same instant as T, arrives - 
critical instant. 
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Figure 5.1: Task Ti s Execution Profile 


The blocks of execution between the points U\,r (The earliest point in 
time after the completion of task T, at which the processor becomes idle) and d t 
(deadline of T) are : (/ 2 , U 3 , . . . , Uk (There are k used time blocks in all). These 
blocks represent the higher priority tasks that would have to be accommodated 
if we want to push the completion time of Ti towards di. Each block of used 
time is divided into marked and unmarked sub-blocks. A sub-block of block Uj 
is said to be marked if the execution that spans it belongs to a task (or tasks) 
that belong to the sub-set S. A marked sub-block, denoted as UJ, indicates the 
p'th marked sub-block in Uj. There are k such marked sub-blocks in all. The 
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way the scaling factor, sf 1 for task T t is computed is as follows: 


s f' = , max sf m 


where 


Sfm = 


H ((£3 Uj) + (^7+1, i ~ 

1 <]<m \ V/ / 

“ mi 


1 < j <m V/ 

•s/m in the equation above is the factor which when used to scale the 
execution times of all tasks in S of higher priority than T t , will be able to 
stretch the completion time of task Ti at most till £/ m+1L . The first term in 
the numerator (same as the denominator) is the total of the execution times of 
tasks in S that are considered for scaling at this point (i.e., tasks in S whose 
priority is higher than T,). The second term in the numerator is the total idle 
time that these tasks are being scaled to consume. Therefore the right hand 
side of this equation in a simplified sense can be viewed as 
Observe that, each sf m is a valid scaling factor in the sense that it does not 
result in T missing its deadline. Since we are interested in the maximum scaling 
factor, the maximum among these valid factors is the required solution. The 
resultant scaling factor sf' is therefore the maximum scaling factor w.r.t task 
Ti . However, from the definition of sf * one can see that the possibility of a 
higher priority task missing its deadline is not accounted for in this factor (only 
its demand is accounted for). Therefore, this scaling factor is valid only in the 
context of task Ti. In order to find a common scaling factor for the sub-set S 
now, we have to find the minimum among all sf' (h < i < n). 
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To understand why the minimum has to be taken, note that w.r.t task 
Ti (h < i < n) any scaling factor value less than sf l will still continue to be 
valid. However, w.r.t some other task Tj (h < i < n), where sf J < sf' 
will not serve as a valid scaling factor. Observe that sf J will surely serve as a 
valid scaling factor w.r.t both T, and Tj. If we generalize this observation, it is 
clear why the minimum is the required solution. 

The complete algorithm to compute maximal scaling factor is given 

below. 


1 Algorithm Scale-Factor (T, S) 


Parameters: T is the given task-set which is schedulable. S is the 
sub-set whose scaling factor is desired. S is assumed to be sorted in 
the increasing order of their priorities. Assume that 7\ is the highest 
priority task in the sub-set S. 

Step 1: For (i = h; i < n; i + +) 

Step 1.1: Compute first approximation for the completion time 
of task T,'s first job: 


complo e j 

] = ltox 

Step 1.2: Calculate the next approximation for completion time: 


com 


^ compl t 

plt + 1 = e. + Ys r 

Pi 


7 = 1 to l—l 


Step 1.3: If (complt+i > d,) then The job missed its deadline: 
Exit(-1 ); 



Step 1.4: If (compl t+x ^ compl t ) then we have not arrived at the 
completion time of the task, so, goto Step 1.2; 

Step 1.5: The completion time for the job is comply 

Step 1.6: Fit higher priority task instances that would arrive 
between the points compl t and efj. The scheduling points are 
U 2 L, U 3 Li • • • , UkL * ■ where, U m = U m R — U m i denotes the m th used 
time block (refer to Figure 5.1). Further we identify each used 
block as a sequence of marked and unmarked sub-blocks where a 
sub-block of block U m is marked (referred to as U^, if it is the j’th 
marked sub-block of U m ) if it belongs to the sub-set 5 and if its 
priority is greater than that of task 7*. unmarked otherwise 

Step 1.7: Compute the maximum possible scaling factor sf': 

s f - . max sf m 

1 <m<«— 1 


where 



Uj) + (Uj+.J, - C/y,H)) 


l<;<m V/ 


Step 2: sf = Minimum {sf') Vi 

Step 3: sf is the required maximal factor. 


4 Uk is the used block of time that overlaps with the deadline d,. However, if the last block 
of used time, Uk , does not overlap with the deadline d*, i.e., d^ < Uk,L then we set Uk l = d t 
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end 

The fact that the above algorithm returns an maximal scaling factor is 
confirmed by the following proof: 

5.4 Proof for the Presented Solution 

Following are the observations about the Solution that would help us prove 
that the derived scaling factor is in fact maximal. 

• There is no idle time in the interval [U\,l, because if there were any 

idle time then it would have been used by T t resulting in Ti completing 
before the point 

• Blocks of execution U x (i > 2) belong to only higher priority tasks. This is 
true because we have not taken any lower priority tasks into consideration 
here. 

• The scaling factor we are trying to find for task T{ only guarantees that 
the task T x will meet its deadline, by using the processor at times when its 
free (i.e., not executing any higher priority tasks). It is possible that the 
scaling factor derived can cause a higher priority task to miss its deadline. 
However, if a higher priority task does miss its deadline, it is not because 
of task T x but due to its own execution time and the execution times 
of tasks higher than itself being scaled (this point is explained using an 
example later). 

To see the effect of scaling the tasks by a factor, we look at the first scal- 
ing factor considered, namely sf\ = ^rj — “ ( re f er to Figure 5.2). 
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Figure 5.2: Effect of Scaling by s J\ 


Since, this scaling does not affect the periods of tasks, if there were instances 
of a task Tj(j < i ) in the interval Ui,l) before the scaling, there will still 

be the same number of instances and further they will arrive at the same points 
as before. 

U\ — U\,R — = ^2 Ij x ej where Ii = 1 

i<j<» 

The processing requirement of task Tj(Vj < *), after scaling would become 
e '] = s f\ x e i> if {j € S), or e' = ej, if ( j g S). However, So long as the 
following condition holds true, task T{ would complete by U 2 ,l'. 

E X O = U ^L 

1 < 7 <* 

We can confirm that this is in fact true: 

E ( 7 > x e 'j) = E ( 7 j x x e >) 

i<i<» (i <j <i)u(jes) 

+ E (t x =.) 

= •s/i x E ( 7 j x e j) 

(1<;<»)&06S) 

+ E ( 7 J X e l) 




61 


(£ u[) + u 2 . l - Ux, R 

_ v/ 

<£ f/ .' ) 

V/ 

+ £ (/i X ei) 

(l<j<»)t(jgs) 

= (£ ^ ) + u 2 , L - u hR 

vi 

+ £ Vi x «,-) 

(l<j<«)tOs!S) 

= + ^2,L ~ U\ ,R 

= t/ 2X 

While the above shows that the scaling factor is valid in the sense that it 
moves (forwards) the completion time of T, to the point U 2 ,l (this argument can 
be extended to show that a factor sf m will forward the completion time of task 
T, at most till U m + \, l), it does not necessarily guarantee to be the maximal 
scaling factor. The maximal scaling factor is the largest such scaling factor 
among all s f m where 1 < m < k. In order to see why this is so, observe that 
any factor sf m would result in the task T, finishing before its deadline, therefore 
all sf m are valid, however, the one that is the largest (say sf max = sf') is the 
desired result. To see why this is maximal, we note that any larger a factor 
would result in T t finishing beyond U ma x+i,L and any smaller would leave more 
room for scaling the tasks in question. 

Observe that computation of scaling factor w.r.t task T\ only guarantees 
that Ti will meet its deadline honoring the processing requirements of all higher 
priority tasks. The scaling factor thus obtained does not guarantee against 
higher priority tasks missing their deadlines. If any higher priority task misses 
its deadline as a result of this scaling, then obviously, it would miss its deadline 
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in spite of T{ and therefore a prior scaling factor would prevail (an example 
below demonstrates this). In this way we compute the scaling factor sf'. We 
perform this computation for all values of i from h io n and find the minimum 
of them, which is the desired final result. 


5.5 Examples Demonstrating the Solution 

The following examples demonstrate the various aspects of the technique. The 
first example involves three tasks, whose characteristics are given in Table 5.1 
and the sub-set S has only one task {T 2 }. 


Table 5.1: Example Task Table 


Task Id 

Period 

Exec Time 

Deadline 

1 

100 

40 

100 

2 

150 

40 

150 

3 

350 

35 

280 


Figure 5.3 gives a pictorial description of how the technique works on 
this example. The required maximal scaling factor is 1.5625. There are a few 
important points to note, that are not evident through this example. The next 
two examples are used to show these. 

The second example demonstrates that, when computing the scaling 
factor w.r.t a given task 7i, it is not necessarily true that the last of the com- 
puted scaling factors, viz., sfk is the maximum of all sf m . To see an example 
of this case, consider the following task-set: 

The task-set T has two tasks and the sub-set 5 contains both of them. 
The computation of sf 2 would be Max( 100/80 = 1.25,145/120 = 1.20) = 1.25. 
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Table 5.2: Example 2 


Task Id 

Period 

Exec Time 

Deadline 

1 

100 

40 

100 

2 

150 

40 

145 


Note that the scaling factor sf 2 is not determined by the second sf 2 (last) 
computed scaling factor but by that factor which is the maximum. In this case 
the factor sfi. This same variation on the example also gives us a case for the 
point we made before, i.e., when computing the scaling factor w.r.t task T x , 
the maximum of all the factors sf m , 1 < m < k is to be taken. Clearly, if we 
were to take sf 2 to be 1.20 (145/120) rather than 1.25 then there would still 
be some room for scaling. 

In example 1, we see that the scaling factors are decreasing as we go 
form task i = 2 (sf 2 = 1.75) to task i = 3 ( sf 3 = 1.5625). This however, is not 
true in general. A simple variation on the example will show us why. Consider 
the task-set in Table 5.3 with S = {T 2 }. 


Table 5.3: Example 3 


Task Id 

Period 

Exec Time 

Deadline 

1 

100 

40 

r ioo 

2 

150 

40 

150 

3 

350 

35 

300 


We now have sf 3 = Mox(85/80, 145/80) = 1.8125. Thus illustrating 
that the scaling factors don’t have to follow a decreasing trend as we add more 
tasks. This example also illustrates that the desired maximal scaling factor is 
the minimum sf\ i.e., 1.75 and not 1.8125. 










Chapter 6 


Schedulability of Task-Sets with Arrivals 


The source of this problem as discussed in Chapter 4 stems from the first stage 
of solving the end-to-end schedulability problem. To recall, the problem of 
interest here is the schedulability of tasks which have end-to-end schedulability 
constraints, i.e., a task is a sequence of sub-tasks that execute on indepen- 
dent components. However, the task as a whole has an arrival time, period 
specification and a deadline requirement. 

We showed in Chapter 4 that a solution to the problem of end-to-end 
schedulability (and subsequently scalability) requires that we are able to solve 
the single component schedulability of a set of tasks whose arrival times are 
non-zero. The reduction was facilitated by an important transformation, viz., 
phase adjustment. Phase adjustment is a technique that allows us to derive 
the parameters of arrival and periodicity of sub-tasks of a task. The princi- 
ple behind the technique was briefly described in Chapter 4, a more detailed 
description follows 

6.1 Phase Adjustment 

Clearly, the parameters of arrival and periodicity of the first subtask of any task 
are known a priori (inherited from the task). However, subsequent sub-tasks 
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T, j (j > 1) of task T x are not necessarily periodic in nature. Therefore, their 
arrivals and their periodicities do not correspond directly to that of the tasks. 
We have to account for this unpredictability in timing behavior of sub-tasks fol- 
lowing the first sub-task. The first sub-task 7b has the same periodicity as the 
original task 7j, therefore, it always arrives (or is ready to execute) at the start 
of the period p x . However, the subsequent sub-task arrival times are dependent 
upon the completion time of the previous sub-task, i.e., if T, : —* T XiJ+x ,j > 1, 
then the arrival time of a particular instance / of Ti, J+1 is dependent upon the 
completion time of th e I th instance of sub-task T tJ . Further, the completion 
time of a sub-task instance is a function of its priority among the other ready 
tasks on the component. Therefore, we observe that there is a dependency 
between successive sub-tasks that has to be taken care of. 

Phase adjustment is a mechanism that allows us to remove this depen- 
dence. Since a, is the arrival time or phase of task 7b sub-task 7b inherits the 
phase of the task T,, i.e, a xX = a x . The I th job instance of sub-task 7b arrives 
at a, + (/ — l)pi- Let the worst-case completion time (or response time) of 
sub-task T, i be WC xX , i.e., any instance of 7b (call it the I th ) would complete 
no later than a,i + (/ - l)p, + WC t We use the term WC xX to adjust the 
phase of the next sub-task 7b- Therefore, the phase of 7b, a i2 is given by 
a xl -p WCi\. This also guarantees that consecutive instances of subtask 7b will 
repeat periodically at an interval of p x time units. 

This can be further generalized to find the phase a t J ,of the sub-task T t} 
as a x ,j - 1 + WCi' } -\. Also all sub-tasks of task T x are now guaranteed to directly 
inherit its period. We have the following a recurrence relation that captures 
the arrival time of a sub-task T XJ : 
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i -b WC t j-\ 

In order to find a closed-form solution to this recurrence relation we have 
to know the base values, a tX and WC t \. We already showed how to obtain a xi 
from a t . The worst-case completion time WCn of sub-task T lX can be obtained 
if we solve the problem of schedulability of tasks running on the component that 
Tn runs. A solution to this problem is the subject of this chapter. Assuming 
for now that we do have a solution to this problem and hence are able to find 
the worst-case completion time of T t j, we complete the requirements to convert 
this to the following closed form: 

j-i 

°ij = a, + £ WCa 

1=1 

Having obtained the value of WC{\ we can now use it to find the arrival 
time and hence the worst-case completion time of task T l2 . Again, we are 
assuming that we know how to compute the worst-case completion times of 
subtasks running on a single component with non-zero arrivals. Note that the 
schedulability test for the end-to-end task T, would now be a trivial comparison: 
if r H\<j<r WCij < D{ then the task T, is schedulable. 

In the above discussion we have assumed that we have a mechanism that 
computes the worst-case completion times of subtasks given their arrival times, 
periodicities and priorities. This is the subject of the following discussion. 
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6.2 Problem Statement and Solution 

We recall from Chapter 4, the formal statement of the problem (Problem 4.2.2) 
of interest to us here: 

Given a task-set T of n tasks executing on a single component , find the 
worst-case completion times of all tasks in the task-set . 

The solution to this problem is based on the following observations: 

1. Is there a period L for the task-set such that, looking at the behavior 
of a task T x during the interval a, and L is sufficient to determine the 
worst-case response time of the task T t ? Note that, if a t = 0, Vi, then L 
is given by the LCM of the task periods. The worst-case response time 
of a task T t is the maximum response time of all instances of T, in this 
interval. 

2. For arbitrary arrival phasings of tasks, the repetition of the initial phasing 
pattern 1 occurs at a point L units later (where L is given by the LCM 
of the periods). The state of the scheduler (defined later) is not the same 
at these two points. Therefore, repetition of phasing pattern does not 
necessarily guarantee that the task-set behavior will repeat itself. 

3. If the task arrival times are inverse monotonically increasing with the 
priority, i.e., the highest priority task is the earliest to arrive (a t < a ; if 
i < j), then the repetition of the phasing pattern is an indication that 
the task-set would repeat its behavior. 


! The phasing pattern is the relative arrivals of the various tasks under consideration 
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4. Given an arbitrary task phasing a, we can derive an alternate phasing a ' 
which has the characteristic that the arrival times monotonically increase 
with the priority. Further, this phasing can be used to determine the 
worst-case response time of the tasks in task-set. 

The following theorem is the basis for the approach. 

Theorem 6.2.1 : Given that the arrival times of tasks in a task-set are inverse 
monotonic with priority (a, < a 3 if priority of T, is greater than priority ofTj, 
i.e, j > i), the worst-case response time instance of a task T, belongs to the 
interval [a*, + LCM(Ti, . . . , T<)]. 

Proof. For task, T,, the only tasks that it would have to compete with, are 
the higher priority tasks 7 i, 72, . . . , 7T We are therefore interested in finding 
that point in time at which, the phasing of task T; (given by + x, x p,, for 
the x \ h instance) with respect to other higher priority tasks is same as that at 
time a,-. Further, this point must be such that the state of the scheduler must 
be same as it was at a,. 

The relative phasing of task T\ with respect to the task T\ can be cap- 
tured as: Task Ti comes a, — a\ units of time after task T\. Assuming the 
existence of a point where this phasing repeats, and further that there are 
xj and Xj instances respectively of 7\ and 7 1 , before this point, we have the 
following condition: 

(a, + x, x p^ - (ai + x t x p x ) = a,- - a. 


=> X\ X p, = Xi X Pi 


We can derive similar conditions for task T, w.r.t other tasks. The 


resultant condition is: 


Xi x pi = x 2 * pi = . . ■ = x { x p t = L 

where a, + L is the desired point. Clearly the LCM of p* is solution for 
the above equation if we assume integral values of p<. 



Figure 6.1: A task-set’s execution between the start and L 


Next, we have to show that the state of the scheduler with respect to 
the task T, is. the same at both points cq and cq + L. We use the method of 
mathematical induction to show this. 

Definition 6.2.1 ; The state of the scheduler w.r.t task Ti at the time of 
arrival of the k’th instance of task T, is given by Sf = {£*,, . ■ - , S*L , } . 
The term Sj it is the amount of time that the task Tj executed for, before the 
point a t + (it — 1) x p, and since its first invocation (taken modulo its period). 




Note that, since the state of the lower priority tasks T } ,j > i do not 
affect the schedulability of the task 7 1 ,, they don’t figure in the system state 
with respect to task T). Also note that, we are concerned only with the state of 
scheduler at points that are arrival times of tasks because we seek to show that 
the state at these points repeats. Further, = 0, because, the last invocation 
of task Ti, viz., k — l’th should have completed before the arrival of the k'th 
instance (otherwise we would have declared that the task missed its deadline 
and thats the end of it). 


Basis: Consider the point a, 4- L where we have already shown that the 
phasing of the task T t is the same as it was at a^. The highest priority task, 
T\ has an arrival at a x + x x x p x and acquires the processor (being the highest 
priority ready task). The duration of time between this completion and the 
arrival of the task, T 2 at <12 + £2 x Pi (refer to Figure 6.1), can be used by any 
of the tasks 7j(2 < j < i). Note that this same duration at the beginning, i.e., 
when the first instance of T x completes and the first instance of T 2 is ready was 
necessarily idle. However, the state of the processor with respect to task T 2 at 
the point a 2 x 2 x p 2 is exactly the same as at the point a 2 , because, the lower 
priority tasks would not affect the completion times of the instances of task T\ 
and further the latest instance of task T 2 would have completed. Therefore, 
the state of the scheduler w.r.t task T 2 at the point a 2 + x 2 x p 2 is same as it 
was at a 2 , viz., {*S' 1 l 2 ,5] 2 }. 


Inductive Hypothesis: Let us assume that the result holds for the 
i — l’th task, i.e., the state of the scheduler w.r.t. task Tj_ 1 at a,_ 1 +x,_i x p,_i , 
viz.^Sf;- 1 ,, . . . 5f: 2i , ,_ 1 ,5, I :T, 1 ,- 1 }as it was at viz., {5,*,^, . . . 5/_ 2>i _ 1 ,5’/_ l>i _ 1 
Note that between the points a,_i + x,_i x p,_ x and a, + x, x p,, the number 


of tasks of priority higher than task Ti that would arrive are the same as in 
the interval a,_i and a x . Further, since the task T x has to complete before its 
deadline (which is less than its period; If it does not then we just report so and 
thats the end of it), each of the higher priority tasks would have gotten the 
same amount of execution time in these two intervals, implying that: 

S% - S*:c_\ = Sl - Sl., V7 < i - 1 

Note that, when j = i — 1 , the terms an< ^ are both 0 . 

Now, since the result we are trying to prove, holds for the task Ti- 1, we have: 


s%-\ = Sl., vj <1-1 

Therefore, 

SI = SI Vj<i 2 

Which implies that the state of the scheduler at the point a, + x, x p, 

is the same as that at a,. Therefore, the result holds for the task T t . □ 

Having shown that both, the phasing repeats after L units of time and 

also that the state of the scheduler is same when this repetition occurs, the 

result follows.O 

In deriving the result in theorem 6.2.1 we have assumed that the arrival 
times of tasks are such that the highest priority task is the earliest to arrive and 
the arrival times increase with priority. However, in reality, this assumption 
restricts the practicality of the result. In the following, we describe a mechanism 
bv which we can get rid of this assumption without hurting the result. 

2 The last term when j = i has been conveniently added because = 0. 
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Given an arbitrary arrival phasing of tasks the following algorithm con- 
verts it into an alternate phasing where the arrival times increase with the 
priorities. 

2 Algorithm, Arb_to_Incr 

Parameters: ax,a 2 ,...a n , and p^,p 2 , . . .p n the arrival times and pe- 
riodicities of tasks Tj, r 2 , . . . T n respectively. 

Result: a\,a' 2 ,.. . ,a' n , 

Initialize: a' = a; 

The first task arrival is unchanged, 
for ( i = 2 to n) do 
If (a, < a'_j) 

y = 1; while (a* + y x p { < a\_ x ) 

y «- y+l; 

end 

a\ «- a< + y x 

end 

end 

end 

We take an example to demonstrate the operation of the above algo- 
rithm. Consider a task-set with four tasks (Ti,T 2 ,T 3 ,T 4 ), with the following 
values for arrival times and periodicities: (ax = 5,a 2 = 3,a 3 = 4, a 4 = 0), 

(Pi = 10, = 10, p 3 = 16, P 4 = 12). The first task’s arrival time remains un- 

changed, however since the task T 2 s arrival is before Tx’s, its new arrival time. 
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Figure 6.2: A task-set’s execution between the start and L 


a 2 , is computed to be a-i + p? which is 13. Now task 7V s arrival time <23 = 4 
is less than a 2 = 13, therefore its new arrival time a 3 is 03 + P 3 which is 20. 
Task T 4 arrives at a 4 = 0 which is less than a 3 = 20, therefore its new arrival 
time a\ is a 4 + 2 x p 4 which is 24. Now the new arrival times of the tasks in 
the task-set are (o', = 5,a 2 = 13, a' 3 = 20, = 24). 

Before we discuss the mechanism in detail, it is important to ascertain 
the relationship between the original arrival phasing and the modified arrival 
phasing. Since, the modified arrival pattern guarantees the repetition of the 
task-set behavior, in order to find the worst-case response time of any task, 
we only have to look for its instances between its original arrival time and the 
point at which the new phasing repeats itself. 

The algorithm for the complete mechanism follows: 


3 Algorithm 




Parameters: a 1 ,a 2 ,...a n , and p\,p 2 , ■ ■ ■ p n the arrival times and pe- 
riodicities of tasks Jj, T 2 , . . . T n respectively. 
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-Find the modified arrival times, a', for tasks by invoking the pro- 
cedure Arb.to Jncr. 

—Repeat for each task T, in turn: 

♦ Determine if the task meets all its deadlines assuming a worst- 
case phasing (i.e., ignoring arrivals). If it does not then, report 

so and QUIT 

♦ Find the completion time of all task instances of Xi occurring 
during the interval a< and a' + LCM{T 3 ,j < i}. 

♦ Find the maximum and report it as the worst-case response 
time of the task Tj. 

end 


6.3 Example Demonstrating the Solution 

Consider the task-set in Table 6.1 below. 


Table 6.1: Example task-set 


Task Prio 

Arrival 

Period 

Exec Time 

Deadline 

wc c 

WC T 

1 

0 

2 

12 

12 

2 

2 

2 

2 

4 

24 

24 

6 

4 

3 

3 

3 

16 

16 

9 

6 

4 

5 

4 

24 

24 

15 

10 


The computation of the response times of tasks in this task-set using 
the mechanism described above is given in Figure 6.3. In the Table 6.1, the last 




two columns give respectively the worst-case response times of the tasks using 
the critical instant assumption and our approach. It is clear that the critical 
instant assumption has resulted in the computation of a higher response time in 
the case of the last three tasks. In order to best appreciate the merit of finding 
the worst-case completion time of a task using the precise test described in 
this chapter as opposed to using the critical instant assumption, we introduce 
a couple of new measures of comparison, viz., apparent slack and slack savings. 

Note that though both these worst-case response times are still within 
the deadline bound, there is a difference in the apparent slack of tasks. We 
define the apparent slack of a task 3 to be the difference between the deadline 
of a task and its worst-case completion time. Note that a positive apparent 
slack for a task guarantees its meeting its deadline. However, a larger apparent 
slack signifies that a task is more capable with regards to, accommodating task 
interdependence (eg., precedence), withstanding temporary overloads, accom- 
modating aperiodics in the system, restricting jitter in end-to-end systems. 

We define a measure called the slack savings , ssj for a task T x as the 
ratio of the gain in the apparent slack per unit real slack: 


WCf - WCl 



Note that in the above example we have chosen the deadlines of tasks to be 
equal to their periods. However, in general the deadlines can be less than or 
greater than the periods. Also note that the example shows that the arrival 
times are monotonic with priority, however, this need not be the case in general. 

3 as opposed to the original slack of the task which is independent of other tasks it has 
to compete with and is defined to be the difference between the deadline and the execution 
time of the task 




Figure 6.3: Operation of example task set 


In the above example we achieve the following slack savings: ss, = 0%, ss 2 = 
10%, ss 3 = 23%, ss 4 = 25%. 


6.4 Discussion of the Result 

The reader will observe that the above treatment of the end-to-end schedula- 
bility problem assumes that all tasks access the components in the same order. 
This scenario is similar to the classical periodic flow shop model [4]. However, 
as will become clear in the following discussion, this assumption can be relaxed. 

We consider the following scenarios for the order in which the tasks use 
the various components: 

• Case 1: Periodic flow shops [15, 4]: All tasks execute on the same com- 
ponents in the same order. Every task Ti has exactly r (the number of 
components) sub-tasks, T,i — » 7^ — *• where each sub-task T :] 

executes on component j. This case is a special instance of the next case, 
however, we treat it separately because of its practical significance. 


• Case 2: The use of components by the tasks are ordered but the tasks 








don’t necessarily access the same resources: We assume that any two 
tasks T„Tj that have subtasks that run on two components R k , Rt , do 
so in the same order in both tasks. Further, the component used by a 
sub-task 7V, is not used by any other sub-task of 7V 

• Case 3: Arbitrary order flow shops: The order in which the components 
are used by a task can be arbitrary (as opposed to ordered access in 
Case 2). There are two possibilities under this case, one which disallows 
components from being reused and the second where components are 
allowed to be reused. 

6.4.1 Periodic flow shops 

If we assume an ordering of the r components in use to be in numerical order 
then the function /?es(7Vj) can be taken to be equal to j (i.e., the compo- 
nent). Therefore we now have n tasks with each task consisting of r subtasks 
where the subtask of every task Ti (Vi) runs on component number j . 

In order to determine the schedulability of the task-set we have to study 
the schedulability of each task in turn. Phase adjustment guarantees that sub- 
tasks of a task inherit its periodicity and further they are independent of each 
other. Therefore the schedulability test for a task 7* is given by: 

a, + £ WCi, < D x 

j=i 

Where, WC X] is the worst-case completion time of the subtask TV,. In 
order to find the worst-case completion of the subtask T tJ which runs on the 
component j we have to consider all the subtasks that run on the component 
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j. Starting from j = 1, we see that for the first component we know the arrival 
times, periods and priorities (note that the subtask priority can be explicitly 
given or the subtask can inherit the original task’s priority) of all subtasks 
that run on it. That is, for a given subtask T t \ , its arrival time is a, and its 
period is p t . We can find its worst-case completion time by the mechanism 
described in the previous section. Let WC X \ be the worst-case completion time 
thus determined (Note that this worst-case completion time is the time taken 
by the subtask to complete after its arrival). 

We now fix the arrival time of the second subtask of Ti (i.e., T x 2 ) as •+ 
WC X \. This fixing of the arrival is a result of the phase adjustment mechanism 
described before. Further it ensures that the second subtask will be periodic 
with period, pi. We now know all the parameters (viz., arrival phasing, period 
and priority) we need to determine the worst-case completion time of the second 
subtasks of all the tasks. Knowing the value of WCi j (Vt) we are able to find 
the timing parameters of the third subtasks and so on. 

6.4.2 Ordered Access 

This a more general case than the periodic flow shop case in that tasks don’t 
necessarily access all the components. However, when they do access a particu- 
lar component its relative order with respect to other components is honored in 
all tasks. We once again assume that the components are numbered in order. 
We do the following modification to the formal specification of this case: 

We assume that each task T, is a sequence of subtasks T xX — * T x2 —> > 
_ T ir - However, if the task T x does not have a subtask running on com- 
ponent j then the corresponding subtask T x] has an execution time, e X] = 0. 



By specifying the model in this way we are able to treat this case similar to the 
previous case. However, note that for all subtasks that have a zero execution 
time their worst-case completion times are also zero. 

6.4.3 Arbitrary order with no revisit 

The major problem with this ordering scenario is that it is not always possible to 
find the timing parameters of all subtasks that run on a particular component. 
For example in Figure 6.4 we see that task T, uses the components in the order 
R2 -+ R4 Rl, task T 2 uses components /?1 — ► /?3 — *• /?2 — ► R4 and task 
X3 uses components R2 —* R3 — ► Rl. Determining the parameters (mainly 
arrival times) of subtasks that run on component Rl, Tj j, 7j |, T33 involves 
finding the worst-case completion times of subtasks T h i,T h2 ,T 3<l andT 3 ^ It 
can be seen that this is not possible without addressing the schedulability on 
the components R2 , R3andR4. 

An alternative approach to this case would be to ignore the arrival 
information of tasks (and subtasks). Note however that the penalty of ignoring 
arrival information is that we end up doing a pessimistic schedulability analysis. 


Chapter 7 


Scalability in End-to-End Systems 


As shown in Chapter 4, the problem of scalability of tasks in end-to-end systems 
manifest itself in two forms, viz., (i) Changes to components and, (ii) Changes 
to Tasks. We have also shown that solving this problem in either of these two 
flavors reduces to solving the following two problems 4.2.4 and 4.2.5. 

4.2.4: Given a task-set T of n tasks (with non-zero arrival times) exe- 
cuting on a single component, find the worst-case completion times of all 
tasks in the task-set. 

4.2.5: Given a schedulable task-set T of n tasks executing on a single 
component and a subset 5 of T, find the maximum scaling factor sf with 
which all tasks in S can be scaled without violating the schedulability of 
any of the tasks in T. 

The first of the two problems was the subject of the previous chapter. 
This chapter is devoted to presenting a solution to the second. As shown in 
the previous Chapter 4, the problem of schedulability in end-to-end systems 
can be reduced to a series of single component schedulability problems. How- 
ever, the single component schedulability problem has to accommodate task 
arrival times. Similarly, the problem of scalability in end-to-end systems can 
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be reduced to a series of single component scalability problems provided we 
accommodate task arrival information into the computation. Further, to find 
the scalability of a sub-task we have to know its deadline and also the deadlines 
of all other sub-tasks involved in its analysis. There is no straightforward way 
to derive the sub-task deadlines. 

A major research issue in end-to-end scheduling has been the derivation 
of sub-task deadlines. Given an end-to-end task’s deadline the problem of find- 
ing an optimal 1 division of this deadline among the sub-tasks is intractable [15] 
(NP-complete [12]). This result has prompted a heuristic approach [4, 15], two 
such heuristics being: (i) divide the task’s slack 2 equally among the sub-tasks; 
(ii) divide the task’s slack among its sub-tasks in a weighted proportion of their 
execution times; 

The above two heuristics vary mainly in their sensitivity to the execution 
times of tasks. For example, the second heuristic is built on the assumption 
that the shorter a task’s execution time requirement, the more likely it will have 
its requirement met and therefore the lower is the slack assigned to it. The 
first heuristic is built on the assumption that the priority inherited by a sub- 
task has a greater impact on its ability to meet its execution time requirement 
than its execution time itself. Thus the slack is divided equally among all sub- 
tasks. This allows us to reduce the end-to-end scalability problem to m single 
component scalability problems. 

'In the sense that, if there exists a division that would help the task meet its deadline 
then the mechanism should find it 

2 The slack of a task is given by the difference between its deadline and its execution time 
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In our research, we have chosen the second heuristic because it is more 
general of the two. The intuition behind the heuristic is to divide the slack of 
the task proportionally among its sub-tasks. We can find the total slack of the 
task T, as si, = d, — Ylv, e ij • We divide this among the sub-tasks in the ratio 
of their execution times, e ,j. Therefore, 

d,'; — Ctj ^ X sli 

e tj 

The following section describes a mechanism for finding the scaling fac- 
tor that incorporates the arrivals of tasks. We also give an informal proof for 
its correctness. In order to simplify the presentation we assume that the scaling 
factor we desire is a common scaling factor for all tasks in the task-set. Note 
that the case of general scaling (sub-set scaling) can be easily derived on the 
same lines. 

7.1 Problem Statement and Solution 

As we did when we dealt with the problem of schedulability using arbitrary 
task arrivals in the previous chapter, we assume that the arrival times of task 
are in increasing order of their priorities. Therefore, the highest priority task 
T\ is the first to arrive (time t = 0) and T, arrives prior to T } if * < J. 

The procedure for finding the common scaling factor of a task set, pro- 
ceeds on the same lines as that for arrival times being all equal to 0. We 
find the scaling factor s/‘, with respect to each task i (1 < i < N) and take 
the minimum as the required result. Any scaling factor sf l has the following 
sense: This is the maximum factor by which all task execution times can be 



scaled such that the task Ti will meet its deadline while continuing to honor all 
higher priority task requirements (not necessarily their deadlines). However, 
the difference comes in the fact that when we are finding the scaling factor with 
respect to a particular task 7 1 ,-, we no longer can settle by considering only one 
instance (the worst-case instance, which is the first instance using the critical 
instant argument) but we have to consider all instances of this task between 
the points a , and a, + L (refer Chapter 6). 

Following are some of the distinguishing characteristics of the problem 
when compared to the treatment in Chapter 5. 

• It would seem that it is sufficient to consider the worst-case execution 
instance (of a task 7*) and apply the same technique as before (as in 
Chapter 4) to find the scaling factor. However, this is not true for the 
following reason: the scaling factor is determined by both the completion 
and the idle time left before the deadline; the worst case-completion of 
a task instance does not necessarily guarantee that the idle time left be- 
tween its completion and its deadline after accommodating higher priority 
tasks is a minimum. 

• The critical instant assumption, in addition to restricting our considera- 
tion to a single instance, has also allowed us to conveniently ignore any 
higher priority tasks that would arrive prior to task T,’s arrival. The pos- 
sibility of the following scenario (refer to Figure 7.1) has to be taken into 
account for arbitrary arrivals: In computing the scaling factor for the first 
instance of task 7’,, we cannot ignore the blocks of execution that precede 
the point a, (i.e., U\ , U?, . . . , U q - \ ). This is so because, it is likely that a 
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factor computed ignoring these could cause the used blocks of execution 
before a x to be scaled in such a way that the begin time of tasks in the 
block that a, belongs to, could be affected by tasks other than the ones 
within. This results in the computed factor being invalid. 



Figure 7.1: Execution Profile Task T/s First Instance 


We now discuss the mechanism along with an explanation of why the 
mechanism works. We are interested in computing the scaling factor s/\ with 
respect to a particular task T{. We once again note that this factor does not 
guarantee that all higher priority tasks would meet their deadlines, it only 
ensures that the task T x will meet its deadline in spite of honoring the require- 
ments of higher priority tasks. 

Let us consider the first task instance of task T{. Assume that there 
is only one block of execution before the arrival of task T x at a< and there 
are a number of blocks after the completion and before the deadline (refer to 
Figure 7.2). We are interested in stretching the deadline as far as possible while 
honoring the requirements of higher priority tasks. The only way this can be 
accomplished is by stretching the completion a step at a time with each step 
attempting to consume the next available idle time (Refer to Chapter 5 for 
reasoning). The required result (the scaling factor with respect to this instance 




of task Ti) would then be obtained by taking the maximum (because all these 
factors are valid and we are interested in finding the optimal one) among such 
computed factors. 
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Completion ofT. 



Figure 7.2: Figure 7.1 assuming q = 2 


We now look at how we can stretch the completion time to achieve the 
motive described above. Since we assumed that there is only one block of 
execution (obviously comprises of at least one instance of every higher priority 
task), following are the points to note while trying to stretch the completion 
time of the first instance of the task Ti to consume the first slot of idle time: 

• If we ignore the block of execution before the arrival of task Ti then the 
scaling factor would be / = . However, it is possible that this 

factor could result in the ignored block (i.e., f/,) being scaled beyond the 
point Ui t L (we call this the unfavorable event for this choice of scaling 
factor, NFEl), thus invalidating the factor. On the contrary, in the event 
that this scaling factor does not scale Ui beyond the point £/ 2 ,i (we call 
this the favorable event for this choice of scaling factor, FEl), this factor 
is clearly valid and effective in stretching the task completion time till 
U 3Z. 




• If instead, we use the scaling factor to be f = U ^{j , it is possible 
that the resultant factor does not scale U\ to occupy the whole of the idle 
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time between {U Xi r, U 2 .l), resulting in (J 2 being stretched beyond U^.l 
and consequently the completion time being stretched beyond U^L ( we 
call this the unfavorable event for this choice of scaling factor NFE2). 
Note that this possibility has come up because the task T t is not ready 
to use the idle time between (U\ < r,U2,l)- On the contrary, in the event 
that this factor causes U\ to be scaled beyond the point U 2 ,l (we call this 
the favorable event for this choice of scaling factor, FE2) then clearly the 
completion time of task T, will be within (in fact it will be exactly 
U 3 x ). 


We note that there are two possibilities (or events) in favor of each of the 
above choices and two that are not in favor. However, we will show that the 
true answer lies in finding the minimum of these two possible factors. That is. 
picking the minimum of these two factors as the solution leads us to realize that 
the unfavorable possibility is actually not possible. An explanation follows: 

We have two possibilities to consider: 

• f < f : The favorable event (FEl) corresponding to this choice of the 
factor is valid in giving us the desired result. However, we have to show 
that unfavorable event, NFEl will not occur. We show this by contra- 
diction: 

Let us say b\ gets scaled beyond the point U 2 , L (i.e, the event NFEl does 
occur). /'. being the larger of the two, using it as the scaling factor would 
scale L\ beyond U 2 .l too. But, since /' has been derived to stretch both 



U\ and U 2 over (0, t/ 3l £, ), if it does stretch into the start of U 2 , then 
there would be no idle time between the points (0, This implies 

that /' < / because, the bumped time 3 , say S (= /' x U x - U 2 ,l ) and the 
scaled (J 2 (= f x (J 2 — U 2 ) together fitted within the interval between 
(U 2 ,r,U 2 'L), whereas / scaled only U 2 to occupy the same interval. The 
conclusion that, /' < / contradicts our assumption that / is the smaller 
of the two factors. Hence the result. 

• />/': The favorable event (FE2) corresponding to this choice of the 
factor is valid in giving us the desired result. However, we have to show 
that unfavorable event, NFE2 will not occur. We show this by contra- 
diction: 

Lets say U\ does not get scaled beyond the point U 2 ,l when scaled by f 
(i.e., the event NFE2 does occur). Since, / > /', U 2 does not go beyond 
Uj,l when scaled by /'. However, the very definition of NFE2 says that 
/ stretches U 2 beyond U$j,. This is a contradiction. Hence the result. 

Observe that the favorable events in both choices of scaling factors 
achieve the following: The completion time of the task T, is stretched to the 
point Uz,l- We now extend this to the case that the number of blocks of ex- 
ecution prior to the arrival of the first instance task Ti is more than one. In 
fact, we wish to extend this argument to the case that there are q — 1 blocks 
of execution before the arrival of the first instance of Ti. The generalization is 
straightforward. If there is more than one block of execution then the scenario 
would be as in Figure 7.1. The scaling factor associated with stretching the 


3 the excess scaled time that was carried from scaling Ui beyond the point L 


completion time of the first instance of task T, to consume the first idle interval 
beyond its completion would be given by: 
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F q = Min 


Uq+\.L - U\,L Uq+hL ~ UjJ. 


U, 


7+1 X 


-U, 


£r = 


1 lo q 


Ur E,= 


2 to q 


U r 


U r 


*) 


Where q is the index of the block that contains the arrival of the first 
instance of Tt (from the fact that there are <7—1 blocks of execution before 
its arrival). Note that this is also the index of the block that contains the 
completion of T,, because, there cannot be any (processor) idle time between 
a task’s arrival and its completion. We represent this factor by F q to signify 
that this is the factor with which all Tj ( j <= t) must be scaled to fill the 
first idle interval after the completion (known to overlap with the block U q ) 
of this instance (the first that is) of task Ti. The subscript q here is only to 
identify the block which overlaps with the completion of this instance of T t . 
The representation will become clear when we proceed to the next stage of 
derivation, i.e., the scaling factor for an arbitrary instance of T, (not just the 
first that is). 

Now consider the point corresponding to the deadline of this instance 
of Ti, a, + d t . Our aim is to try to extend the completion of this instance 
at most till this point. Clearly, if this point overlaps with a used block (call 
it Uk+ij,), then we cannot possibly extend T/’s completion beyond the start 
of this interval. This is obvious from the fact that the overlapped block in 
question contains executions of higher priority tasks that cannot be preempted 
by Ti. On the other hand if the point in question does not overlap with any used 
block then we can consider filling only part of the idle interval that contains this 
point, viz., the idle interval between the right end of the used-block preceding 



the deadline point and the deadline point itself. In this second case, we set 
tw = a, + d, = Uk+\,Rj i-e-i we create a zero sized used block that overlaps 
with the deadline. Here k is the index of the used-block that precedes the 
deadline. 

Therefore, if we assume that there are k - q such idle intervals beyond 
Uq and before the deadline of this instance at d } then we have to find k - q 
such scaling factors F m (that is q < m < k). Accordingly, k is the index of the 
used-block that precedes the deadline point ai + d{. Now, the general formula 
for F m is given by: 

F m = Min ( ~ UhL ~ Um+i ,l ~ Uq,L 

V 5Zr=l to m Ur 5Zr=3 to m Ur X ',r=q to m U T 

The scaling factor for the first-instance of 7^ is the maximum among all 
computed factors for accommodating the next idle interval. Clearly, each of 
these factors is a valid factor in the sense that it does not extend the completion 
time of the first instance beyond its deadline. Therefore, the required factor is 
the maximum among such valid factors given by: 

— MttXq^m^ k F n 

We now have to generalize the above formula for any arbitrary instance 
of Ti (say the /’ th). Clearly there are x, (refer to Chapter 6 instances of T, that 
have to be considered. Therefore, / ranges from 1 to X{. If we find the scaling 
factors sf tl for each of the x % instances of Ti then we can obtain the scaling 
factor sf' as the minimum among all these. This is clear from the fact that 
picking a factor larger than the minimum results in at least one of the instances 
missing its deadline. So. we have: 
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sf' = Mini<i< x , sf' 1 

Before, we find the general scaling factor sf * l of an arbitrary instance of 
r,, it is important to notice some important considerations in dealing with the 
second instance (which will easily extend to arbitrary instances). The second 
instance of 7) is ready at time ai+p x . Its ability to start (i.e., get the processor) 
is affected by higher priority tasks arriving beyond the point a, + p, and, also 
those tasks executing between the deadline of its previous instance at a t + d, and 
the point a, + p,. Note that, we have already taken care of tasks arriving before 
the point a, + d< in finding the scaling factor of the first instance. Therefore, the 
point a^ + di for task TV s second instance is equivalent to the point Oi (assuming 
that the task arrivals are in increasing order; further this point can be taken 
to be t = 0). In finding the scaling factor for this instance, we have to consider 
used-blocks from that which overlaps a x + d, (if this is a zero-sized block then 
consider the next block), to the block that contains the arrival a, + p, on one 
side. On the other side, we have to consider used-blocks between the block 
that contains a< + p x to the block that contains the deadline of this instance 
at ai + pi + d x (remember that if there is no such block that overlaps with the 
deadline then we create a zero-sized used-block to overlap it). 

Now in the general case, that is, when we wish to find the scaling factor 
for an arbitrary instance / we define the following notation (refer to Figure 7.3): 

• u: U v is the used-block that contains the deadline of the (/— l)’th instance 
of TV If however, U v is a zero-sized block then v is the index of the next 



block following the deadline of the (/— 1 )’th instance at a t +(l- 1) xp,+d t . 
As a special case, for the first instance v = 1. 

• q: Is the block that overlaps with the arrival of the /’ th instance of task T x . 
This is also the block that contains the completion of the /’th instance. 

• k: Uk+\ is the block that contains the deadline of the /’th instance at 
a » + (/ ~ 1) x p« + dj. Note that, if the deadline does not overlap with a 
used block then we create a zero-sized used- block at a, + (/ — 1) xpj + d,. k 
is then given by the used-block that precedes this newly created zero-sized 
block. 


The formula for the scaling factor of an arbitrary instance (say /) of T x 
(represented as sf' 1 ) is now given by: 


sf' 1 = Afai,< m <fc F m 


where F m is given by: 


\ to 


Uy,L Um+\ % L ^A/+l ,L 


u, 




-u, 


Ur ’ £,= 


v-M to m 


U T 


£r= 


q to m 


1,L 

U r 


We now have the scaling factor (s/‘) with respect to a task T t . In 
order to find the final common scaling factor sf we follow the same lines as in 
Chapter 5. Therefore, the required scaling factor sf is given by: 


sf = Miri\<i< n sf 


The complete algorithm to find the scaling factor for task T t follows: 


4 Algorithm Scale_Factor (T,) 
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C ample*] oc of l'lh instance of task T, 
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Figure 7.3: Execution Profile of the /’th instance of T, 
Variables: 


/ = 0: task instance 

s f' 1 : the scaling factor for task i instance /. 

Step 0: Initialization. s/‘ = oc 

Step 1: For each task instance / of T t between a, and a, + £ Repeat 

Step 1.1: Find the completion time for the job l = comply 
Step 1.2: 

Fit equal and higher priority task instances that would arrive be- 
tween the points G and a.i + (l + 1) x <£. The point G is ai for the 
first instance, l = 1 and for subsequent instances, / > 1 it is given 
by the deadline of the previous instance, a* -I- / x <£. 

The scheduling points are, U\,l, U^.l, ■ ■ ■ , Uk,L- where, U m = Um.R — 
U m< L denotes the m th used time block (refer to Figure 7.1). 

The used interval among these blocks which overlaps with dj + / x 
P i is = q (note that this is also the block that contains compl t , 
because there can be no idle time between the instances arrival and 
it completion). 


Step 1.3: 




Compute the scaling factor s f tl for job 1: 


M ax„< m < k F m 


where: 


C aa — ( Um+\,L U\ ,L Um+l,L ~ 

\ Z^r=l to m Z-^r=2 to m 

Step 1.4: if {sp l < sf') then sf' = sf' 1 . 

Step 2: sf 1 is the desired scaling factor for task T,. 


U, 


m+1 ,L 


-u, 


m.L 


Ur, 


end 


Having obtained the scaling factor s/' for each i in turn we can now 
determine the optimal scaling factor, sf for the task set, which is the minimum 

of 

7.2 Example Demonstrating the Solution 

To demonstrate the solution we take an example with three tasks whose char- 
acteristics are given in Table 7.1. The timing analysis is shown in Figure 7.4. 
The scaling factor derivation for the first task is straightforward. The deriva- 
tion for the other two tasks is shown in the figure. The common scaling factor 
for this example task-set is 1.6363. 

We compare the scaling factors obtained by taking the approach in 
this chapter as opposed to the critical instant approach followed in chapter 5 
to appreciate the benefits. If this task-set was subjected to the approach in 
chapter 5 then the common scaling factor would be 1.3636. Using the approach 
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Table 7.1: Example Task Table 


Task Id 

Period 

Arrival 

Exec Time 

Deadline 

l 

12 

0 

2 

12 

2 

24 

4 

4 

24 

3 

16 

3 

3 

15 


described in this chapter we get a scaling factor of 1.6363. This is a huge gain 
considering that it is a multiplicative factor and not additive. This will become 
more evident if we express the improvement in execution times as percentages. 
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Figure 7.4: Operation of example task set 





Chapter 8 


Admission Control for Real-Time 
Communication 


The model assumptions in this chapter are based on the Real Time Chan- 
nel model described in Chapter 2. Admission control is the mechanism by 
which multiple real-time connections can simultaneously share the resources of 
a packet switching network without resulting in congestion. Further, the con- 
nections are guaranteed a particular quality of service (QoS) that is initially 
(at connection set up) agreed upon. Admission control comes into play when a 
new RT channel is being requested. An RT channel (or a connection request) is 
accompanied with a QoS list that describes the requirements of this connection. 
Popular QoS requirements in the literature of distributed real-time systems are 
- throughput, latency (or deadline), packet loss tolerance [17, 28. 10, 35, 32] 
etc. 

The mechanism used to determine the admissibility of a real-time chan- 
nel involves verifying at each intermediate link (along the path) in turn whether 
the RT channel’s QoS requirements can be guaranteed. If a channel’s require- 
ments can be met at each of the intermediate links then we can accept the 
channel. If however, the channel’s requirements cannot be met at any of the 
intermediate link then we can reject the channel. In fact the first such link that 
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deems the channel inadmissible is sufficient to confirm that the channel would 
not be admissible. 
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In order to test whether a channel’s requirements will be met at an 
intermediate link we have to know its deadline and its period at each of that 
link. Finding the period is straightforward according to the phase adjustment 
mechanism. However we do have to derive the deadline of the RT channel at 
intermediate links. Since the service time of the channel on each of the links 
is the same one way to derive the deadlines would be to divide the slack of 
the RT channel equally among the intermediate links. However, if one wishes, 
one can use a more sophisticated heuristic [15, 4, 47] to derive these deadlines. 
This reduces the problem of finding the admissibility of an RT channel to be 
equivalent to solving the admissibility at each of the intermediate link [11. 18]. 
From here onwards when we refer to the admissibility of an RT channel we 
mean its admissibility at an intermediate link. 

Now, the question that admission control has to answer when accepting 
a new connection can be broadly phrased as: 

• Given the QoS requirements of a new RT channel is it possible to accept 
this channel without violating the QoS guarantees made to RT channels 
that have already been accepted? 

The principle followed by researchers (for example Tenet [8, 9]) in the 
design of an admission control scheme is based on verifying, whether the re- 
sources available on the path of the newly requested RT channel are sufficient 


even in the worst possible case, to 



1. provide the new RT channel with the QoS it needs and, 


2. allow the guarantees offered to all the existing RT channels to continue 
being satisfied. 

The above verification depends upon the kinds of QoS parameters al- 
lowed. The most important QoS parameter of concern to real-time system 
designers is the meeting a latency bound (deadline). We restrict our interest 
to this parameter. There are two tests that are relevant in this context: 

• Schedulability Test: Does the addition of the new channel to the already 
established channels using this link cause either the new channel or one 
of the already established channels to miss their deadline? 

• Buffer Space Test: Is the available buffer space at the link sufficient to 
allow the messages of the new channel to be stored for a length of time 
equal to the delay faced by the channel at this link? 

Different approaches to the admission control problem (in real-time sys- 
tems) will differ in the way the above two questions are answered. Therefore, a 
study in admission control reduces to the study of these tests. The buffer space 
test has been successfully addressed by the Tenet group [9]. We concentrate 
mainly on the schedulability test because it is our belief that there is room 
for improvement here. In particular, there are many situations that have not 
been considered in this context. We broadly classify two situations which differ 
in terms of the assumptions made about the scheduling mechanism used to 
schedule channels on the intermediate links. 
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8.1 Dynamic Scheduling of RT Channels 

The Tenet schedulability test involves a deterministic test at each intervening 
link along the path. An assumption is made that the scheduling mechanism 
used at an intermediate link is based on the EDD [9] (earliest due date or pop- 
ularly referred to as the earliest deadline first). The test is based on extending 
the fundamental task scheduling result by Liu and Layland [24] to message 
communication. It can be summarized as follows: A given set of RT-channels 
(at a particular link) is schedulable 1 by the EDD policy if the sum of the uti- 
lizations of the RT channels is less than one. The utilization of the i th RT 
channel whose characteristics are a message service time of rrti and a message 
inter-arrival time of g, is given by, u, = mi/gi. If the current total utilization 
at a link is Udet then the utilization as a result of accepting the new connection 
( i th ) would be Udet = Udet + m* /<7i, and the schedulability test would be to 
check whether Udet < 1. 

We have taken a different approach to the schedulability test that is 
based on the scaling problem defined in Chapter 4. The principle involved 
in the test can be described as follows. At each intermediate link an admit- 
tance measure is computed that essentially captures the tightness of the traffic 
already passing through the link. A new connection request is allowed or dis- 
allowed depending upon whether a specific relationship between this measure 
and the new connection’s characteristics is satisfied. The computation of the 
admittance measure is dependent upon the choice of the scheduling mechanism 
and the characteristics of the connections already accepted. Further the tested 


'all the RT channel deadlines will be guaranteed to be met. 



relationship referred to above, is a heuristic comparison between the current 
admittance measure and the new connection’s characteristics. 
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The admittance measure we use is the scaling factor (refer to Chapter 
4) with which the message service times of channels already accepted can be 
multiplied by, so that the channels’ requirements can still be guaranteed. The 
new connections characteristics are captured by its utilization demand. The 
heuristic used can be explained as follows. Intuitively, the greater the scaling 
factor greater is the potential to allow a new connection. Further, the room for 
accommodating new connections is intuitively captured by the term, 

s J n — 1 

This expression, can be viewed as the percentage improvement possible in the 
utilization of the existing channels. The expression can be simplified into the 
form, 1 — . We show later, how this heuristic turns out to be equivalent 

to the deterministic test of Tenet (in the context of EDD that is). 

The following table, shows a comparison of our approach (using the 
scaling factor) and Tenet’s approach. The scheduling mechanism chosen at a 
link is assumed to be the EDD. We later show how the two approaches are 
equivalent. 


Table 8.1: Admission Control Test 


Approach 

Computation 

Test 

Tenet 

U n *— U n -\ + 

9n 

U n < 1 

Scaling 

s fn—\ (precomputed) 

< 1 — V— 

— 2n s fn-i 


The second column in the table gives the computation that has to be 
done in order to test for the admissibility of a new channel. This test can either 
be done at the time the new connection is made (Tenet’s approach) or it can be 
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precomputed (our approach). The advantage of completing this computation 
before the channel is requested is that it will cause minimal delay in ascertaining 
admissibility. Further, it affords the designer to attempt a more sophisticated 
computation because it is done prior to the actual channel admission test. The 
third column gives the test performed when a new connection is requested. 

We now show how the two approaches given in the table are equiva- 
lent. In the case of Tenet, the admissibility test can be viewed as a simple 
comparison to check if the total utilization resulting from the addition of the 
new channel is above the allowed bound (1). Observe that the computation 
in the second column involves the characteristics of the new connection, thus 
making it a computation that has to be performed when the new connection is 
requested. We can however, modify Tenet’s approach so that the computation 
(just compute is independent of the new channel characteristics and can 

thus be done before hand. Further, this modification would result in the test 
changing to: ^ < 1 — Vn-\- 

The reader is referred to Chapter 5 for a discussion of the scaling factor 
problem. More specifically, in section 5.2, a special instance of this problem 
is identified when the subset to be scaled S is the same as the given task-set 
T . It was shown that the common scaling factor (in the case of EDF) is then 
given by the reciprocal of the total utilization of the RT channels. 

&fn— 1 > m, 

2-l<«<n-l g, 

1 

tfn-1 

The test in third column can therefore be interpreted as the < 
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l — U n -\. Therefore, we see that the two approaches reduce to be the same. 
Observe that, the computation of the scaling factor, is more involved 

if the scheduling mechanism is not EDF. This is the subject of the following 
section. 

8.2 Fixed Priority Scheduling of RT Channels 

Our next concern is to extend the approach described in the previous section 
to, general fixed priority preemptive scheduling mechanisms. Note that the 
Tenet approach is only valid for dynamic preemptive scheduling. We use the 
same approach to admissibility as described in the previous section, except 
that we have to pay special attention to the computation of the scaling factor. 
We concentrate our attention to extending our approach to incorporate the 
Rate Monotonic Scheduling (RMS) mechanism (a particular instance of the 
fixed priority preemptive scheduling mechanism). An extension of the approach 
to Deadline Monotonic Scheduling and more generally to any arbitrary fixed 
priority scheduling mechanism is straightforward. 

As we already have seen in Chapter 4, there is no straightforward way to 
compute the scaling factor of a set of tasks (read as RT channels in the present 
context) scheduled by a general fixed priority scheduling mechanism. However, 
in the particular case of RMS, we can find a non-optimal scaling factor that is 
given by: 

rrm , (n - l)(2 1 / (n ~ , > - 1) 

sfn-x = 1 ^77 ( 8 . 1 ) 

t'n— 1 

This factor is not optimal in the sense that it is possible to improve it further. 
Unlike task schedulability where we were interested in an optimal scaling factor, 
in the current context (admission control that is) the above computation does 
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carry a certain merit as will be demonstrated shortly. Though the heuristic 
used in the admissibility test reduced to the deterministic test in the context of 
EDD, this is not necessarily true in the current context. In other words, failing 
to pass the heuristic test does not necessarily imply that the new channel will 
interfere with the schedulability of the already existing channels. This implies 
that, using the heuristic it is possible that a new channel request is rejected 
even though it could have been accommodated. 

An alternative to the above computation is to use a more precise com- 
putation, one which would help us obtain an optimal scaling factor. We have 
shown in Chapter 4, how such a computation works. This alternative is ap- 
pealing in its ability to reduce the number of rejections (as described in the 
previous paragraph). However, it does not necessarily guarantee 100% admis- 
sibility. 100% admissibility is said to be achieved if the test never rejects a new 
channel that would have not interfered with already accepted channels. The 
failure of this alternative to ensure 100% admissibility is due to the fact that 
though the scaling factor computation is precise, the comparison in which it is 
used is a heuristic. 

It is important to observe that, the scaling factor computation is not 
performed at the time of a channel request and therefore we can afford the cost 
involved in finding an optimal scaling factor. However, if the benefit (reducing 
the number of rejections) obtained by using the optimal scaling factor is not 
large enough (compared to using the non-optimal computation), we cannot 
justify it. Since, the basis of the test is a heuristic, the only way one can 
confirm the benefits is to perform a simulation study. 



Simulation Study 

The goal of this study was to compare the two alternatives for admission control 
(described above) when the underlying mechanism used to schedule the RT 
channels is the Rate Monotonic Scheduling. An RT channel is characterized, 
among other parameters by the source and destination of the channel. This 
information is used to find the route of the RT channel. As already described 
the admissibility test of an RT channel that traces a route of, say k links, 
reduces to ascertaining its admissibility at each of the k links in turn. Therefore, 
we restrict our study to admissibility at a single link. From here onwards when 
we refer to the characteristics of an RT channel we don’t mean its end-to-end 
characteristics but its characteristics at an intermediate link. 

We use the following notation in the following discussion: 

x ~ U (a, b) to indicate that the random variable x is uniformly dis- 
tributed over the interval from a to 6. 

x ~ iV(/x; <r) to indicate that the random variable x has a normal distri- 
bution with mean n and standard deviation <r. 

There are two major steps to the simulation study: 

1. The workload generation. The workload of interest to us is the generation 
of characteristics of n RT channels at a link. We would like to characterize 
the workload with a set of parameters that capture its essence. We use 
the following two parameters to characterize (and distinguish between) 


workloads: 
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(a) The utilization U , of the set of RT channels is used to identify the 
cumulative demand of the workload. 

(b) The laxity factor /c, dictates in addition the closeness of the deadline 
to the end of the period of the RT channels. 

2. The simulation of the alternatives and their comparison. The two al- 
ternatives of concern to us are, using the non-optimal scaling factor vs. 
using the optimal scaling factor in the admissibility test. The details of 
the comparison are explained later. 

Before we explain the generation process, it is important to understand 
what we are attempting to generate. We are interested in generating a workload 
of n RT channels with a total utilization of U . For each RT channel C t , we 
wish to know its service time mi, its inter-message generation time g, and its 
deadline <£. 

The following parameters were used in the generation process. 

n: The number of RT channels in the link, 
m: The mean service time of an RT channel. 

U: The total utilization of the n RT channels. The utilization of an RT 
channel Ci with service time m, and and inter-generation time of g t is 
given by m,/#. 

/c(0 < k < 1): Is the laxity factor. 

/i<(0 < Hi < 1): This parameter controls the laxity of an RT channel. The 
deadline of an RT channel C, with a laxity of / is given by m, + / x ( < 7 , — m, ) . 
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Therefore, greater the value of / (directly controlled by /x,), closer is the 
deadline to the period and more is the room for meeting its deadline. 

<t ( : The standard deviation of the normal distribution of the laxities of 
the channels. We constrain this parameter so that following conditions 
hold: 

mui — 3 x (Ti > 0 and 
mut + 3x(j|<l 

The above two conditions guarantee [16] that the majority (as 99.98%) 
of the samples derived from the distribution, W(/x/,< 7 /) are within the 
bounds(0 and 1). 

The approach taken for workload (n RT channels) generation can be 
described as follows. We generate the characteristics of each RT channel C, in 
turn. 

1. The service time m,- of channel Ci is derived from a uniform distribution 
over the range [1,2 x m]: 

m{ ~ f/( 1 ; 2 x m) 

2. The utilization of U{ of channel C, is derived from a uniform distribution 
over the range [0,2 x ^]: 

Ui ~ f/(0; 2 x — ) 
n 

3. The inter- generation time (or period) g if of channel C, is obtained by 
using its service time and utilization already generated above, as: 

m, 

9> = — 

u, 
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4. Channel C,’s deadline d, is obtained as: 

d, = m, + k x (g t - m.) 
where k ~ N(fii,<ri) 

A special case of interest in the simulation (discussed below) we need a 
workload where the laxity factor of the RT channels is a constant. We can 
generate a workload with such a characteristic by assigning the parameter 
<7/ to be equal to zero and the parameter fii to equal the constant desired. 

Having generated the workload we are now in a position to compare 
the two heuristic alternatives against the generated workload. As explained 
before the test mechanism we use to determine whether a new RT channel 
C n (m n ,g n ,d n ) can be admitted at a link, having already accepted n — 1 RT 
channels is given by: 

9n 1 

Where the term s f n -\ is the factor by which the n— 1 (already accepted) channel 
service times can be scaled without violating their schedulability requirements. 
The two alternatives we are interested in comparing differ in the way this 
scaling factor is arrived at. 

• 1Z: Uses the non-optimal computation of s/ n _i given by Equation 8.1. 

• S\ Uses a precise (optimal) computation of the s/ n _i described in Chap- 
ter 4. 

In order to explain the criteria that were chosen for the comparison it 
is important to understand that the workload generated (of n RT channels! 
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is arbitrary in the sense that they can be either admissible (together) or not. 
For a given workload however, we can test whether it is schedulable or not. In 
other words, whether all the RT channels can be accommodated together or 
not. We refer to the outcome of this test as the admissibility (denoted by A) 
of the workload. 

Observe that the above test finds the admissibility of a workload whereas, 
the heuristics are designed to test whether a given RT channel can be admitted 
to an already existing list of RT channels at a link. In other words, the out- 
come A can be either, Ay ea : the workload can be admitted together, or An 0 : 
the workload is not admissible together. On the other hand, the outcome of 
the heuristic Ti. (TZ or «?) test can be either, admit the new channel, or 

Hno do not admit the new channel. However, the heuristic TVs decision can be 
compared against A by defining the following criteria: 

1. If the heuristic H arrives at the decision 'H yet when the workload is in 
fact admissible (Ay et ), then we say that the heuristic has succeeded on a 
YES match. 

2. If the heuristic 7i arrives at the decision H no when the workload is in 
fact inadmissible (An 0 ), then we say that the heuristic has succeeded on 
a NO match. 

3. If neither criterion 1 nor criterion 2 are met then we say that the heuristic 
hits failed. 

Note that the reason for having two criteria for a match is because the 
generated workload was arbitrary in the sense that it could either be feasible 
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or not. While we are primarily interested in a heuristic’s ability to admit 
(reach a YES match that is) an RT channel, we cannot ignore the impact of 
an incorrect decision. The ability of a heuristic to reject infeasible workloads 
(captured by criterion 2) is important in that it gives us an idea about the 
heuristic's sensitivity. For example, it is possible that the heuristic admits a 
new channel to only realize later that it would result in one or more of the 
channels’ guarantees being violated. 

For a given total utilization U and number of channels n (input parame- 
ters), the simulation involves generating workloads of n RT channels and testing 
the admissibility of each of them. Before we use one of the two heuristics ( 71 
or S) to determine whether they admit a given channel, we first ascertain the 
admissibility of the workload (A described before). Next, for each RT channel 
(say Ci) in turn we test its admissibility (using a heuristic) assuming that the 
n — 1 other channels have already been accepted. The test is repeated with the 
two heuristics we are attempting to compare. If the heuristic we are testing is 
say Ri then the outcome of the test can be one of Hyes (admit the channel C,) 
or H no (don’t admit the channel C t ). We now compare this outcome against 
the outcome from the admissibility test for the workload A which was already 
computed. The comparison follows the criteria explained before. With respect 
to this channel we record whether the heuristic achieved a match (could be a 
YES or NO) or has failed. The simulation records the same for each channel 
in turn and obtains the heuristic’s performance on this particular workload 
(This is repeated for the other heuristic also). 

The performance of a heuristic for a given workload is characterized by 


three parameters: 



1. The percentage of (the total n admissibility tests) tests that result in a 
YES match. 

2. The percentage of (the total n admissibility tests) tests that result in a 
NO match. 

3. The percentage of (the total n admissibility tests) tests that result in 
failure. 

Observe that, the generated workload is only one of an almost infinite 
possible workloads with the same input parameters. Therefore we repeat the 
above experiment for a large number of workloads and take an average perfor- 
mance. Further we repeat this for different values of k (or /i; and sigma,). The 
results of the simulation are presented in Appendix A. 

Simulation Results 

The performance measure of primary interest to us is the admissibility of a 
heuristic. And, we are interested in comparing the two heuristics to see which 
of the two is better at admitting channels. Therefore, the graphs we present 
here compare the performance using the percentage YES match (see above). 

Recollect that, the heuristic 1Z assumes that the underlying scheduling 
mechanism is the rate monotonic scheduling. It has been shown that the RMS 
is an optimal scheduling mechanism [20] if the deadlines of tasks are a constant 
factor of their periods. Therefore, we assume that the parameter k is a constant 
and not derived from a distribution. This assumption was made in order to 
choose a scenario that is favorable to both heuristics (and not biased to either). 
This assumption however has no impact on the second heuristic 5. 
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Each graph is identified by the number of channels considered and the 
parameter k. The x-axis gives the total utilization of the workload and the 
y-axis gives the success of the heuristic. For low utilizations (less than 50%) 
there is no need to do a complex test because the demand can be easily met. 
We chose four different values of the number of channels (4, 8, 12, 16) and 
varied the parameter k between 0.5 to 1.0. It was observed that values of k 
less than 0.5 resulted in too many channels missing their deadlines. 

Observations 

• For low utilizations (less than 0.7) we observe that both the heuristics 
have a similar admissibility. Given that the heuristic It is less expensive 
(computation time- wise) than «S, under conditions of low utilizations one 
can choose the heuristic It. 

• For a given value of n and k we observe that the admissibility of heuristic 
Tt falls abruptly beyond a point on the x-axis given by the utilization 
bound. For example, in Figure A. 6 we can see that the heuristic 7 1 
begins to reject channels when the total utilization crosses beyond 0.72. 

• The performance of S degrades gracefully beyond the utilization bound. 
For example, in Figure A. 6 we can see that the heuristic 5 continues 
to admit channels up to a total utilization of 0.92. The probability of 
acceptance decreases gradually (and steadily) however. This implies that 
the heuristic has a better ability to adapt to temporary overloads [43, 26] 
(increased demand from one of the channels) in the network traffic. 


• As the number of channels increases, the performance degradation beyond 
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the utilization bound is slower in the case of heuristic S. This goes on 
to support the ability of the heuristic to adapt to temporary overloads 
(increase in the number of channels). The two sources of overload have 
been successfully handled by the heuristic S. 

• As the number of channels increases the success of the heuristic <5 im- 
proves compared to the heuristic 7Z. 

• In conclusion we can say that for low utilizations both heuristics have 
similar performance (however one should prefer the heuristic 71 due it 
computational ease) but, at high utilizations S far outperforms 7Z. Fur- 
ther, we can justify the cost of computation involved in S by noting that 
the computation can be done before the actual channel request is made. 



Chapter 9 


Summary of Results 


As an example to demonstrate the results reported in this thesis, we choose 
the “Olympus Attitude and Orbital Control System”(AOCS). A detailed case 
study of this real-time system can be found in [5, 46]. The AOCS subsystem of 
the Olympus satellite 1 acquires and maintains spacecraft positions as desired. 
A detailed analysis of this system was performed by A. Burns and his colleagues, 
as a result of which they have summarized a list of tasks (Appendix B, Figures 
B.l, B.2 and B.3) that capture the system’s functionality. They have identified 
mainly two classes of tasks viz., periodic (Figures B.l, B.2) and sporadic tasks 
(Figure B.3). 

The class of periodic tasks in the AOCS case-study are consistent with 
our definition and treatment of periodic tasks in this thesis. Sporadic tasks 
on the other hand are tasks whose periodicity and arrival time are not known. 
However, there is a known minimum interval between successive arrivals of 
these tasks. Also the arrival time parameter of a sporadic task is not known a 
priori due to the nature of these tasks. Sporadic tasks typically occur due to 
events such as exceptions and interrupts which are triggered by a logical state 

‘The Olympus satellite was launched in July 1989 as the world’s largest and most powerful 
civil three-axis-stabilized communications satellite. It provides direct broadcast TV and 
’distance learning’ experiments to Italy and Northern Europe. 
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of the system or an external event. These events are therefore a function of the 
run-time characteristic of the system. 
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The treatment in this thesis has been restricted to handling only pe- 
riodic tasks, however we can accommodate sporadic tasks by making a few 
observations about their behavior. The minimum inter-arrival time parameter 
associated with a sporadic task is a lower bound on its periodicity. For the 
purpose of this chapter we choose the periods of sporadic tasks to have values 
ranging from the minimum to the average periods of periodic tasks. Accord- 
ingly the chosen values of periods for sporadic tasks have been listed in the 
tables. Further, we have chosen the arrival times of these tasks to be zero, in 
other words that the first occurrence of these tasks is at time t = 0. Clearly, 
this is only one of the many possibilities but is sufficient to demonstrate our 
point of interest here. 

The following sections use this task-set to demonstrate the results re- 
ported in chapters 5 to 7. 

9.1 Scalability in Uniprocessor Systems 

The above task-set (say T) is given for a uniprocessor system, where all the 
tasks are known to execute on a central control computer. In order to apply 
the result given in Chapter 5 we have to choose a subset (say 5) of tasks in the 
task-set that are to undergo scaling. For a lack of better knowledge about the 
tasks we pick S = T, i.e., we are interested in finding the maximum common 
scaling factor for all tasks in the task-set. Table 9.1 gives the results of this 
analysis: 


Table 9.1: Task Table with Scaling Factors 


Task Name 

Priority 

Period 

Arrival 

Exec 

Deadline 

Scale Factor 

BUS-INTERRUPT 

62 

50 

0.00 

0.18 

1.00 

5.5556 

REAL-TIME-CLOCK 

27 

50 

0.00 

0.28 

9.00 

19.5652 

READ-BUS-IP 

23 

10 

0.00 

1.76 

10.00 

4.5045 

COMMAND-ACUTUATORS 

20 

200 

50.00 

2.13 

14.00 

2.2989 

REQU EST-DSS.DATA 

19 

200 

150.00 

1.43 

17.00 

2.2546 

REQUEST.WHEEL.SPEEDS 

18 

200 

0.00 

1.43 

22.00 

2.2296 

REQUESTJRES-DATA 

17 

100 

0.00 

1.43 

24.00 

1.9736 

TELEMETRY-RESPONSE 

15 

200 

0.00 

3.19 

30.00 

1.9543 

PROCESS JRES-DATA 

14 

100 

50.00 

8.21 

50.00 

1.8463 

READ-YAW .GYRO 

12 

500 

0.00 

4.08 

100.00 

2.4740 

CONTROL-LAW 

8 

200 

50.00 

22.84 

200.00 

2.18770 

PROCESS-DSS-DATA 

6 

1000 

200.00 

5.16 

400.00 

2.1748 

CALIB RATE-GYRO 

5 

1000 

200.00 

6.91 

900.00 

2.1645 

TELECOMMANDS 

4 

500 

0.00 

2.50 

187.00 

1.7941 

Scaling Factor for S 



= 

1.7941 


The mechanism used to find the scaling factor in the uniprocessor sce- 
nario is based on the critical instant assumption. This result can be easily 
improved by using a more precise mechanism that is based on the results in 
chapter 7. However, as discussed in chapter 4 the critical instant assumption 
is more suitable in uniprocessor systems. Further, it makes the scaling factor 
computation more efficient and cheaper (in terms of processing time). 

Another perspective of the scaling factor can be expressed in terms of 
the utilization. The utilization of a task T, is given by the ratio of its execution 
time to its periodicity, jj*-. The total utilization of the task-set before scaling is 
given by: 
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For the task-set in our case study this is given by: 0.4619. The utiliza- 
tion of the task-set after the scaling is performed is given by: 

ir—ixY. -+ £ - 

>65 P* jGT-S Pi 

Where, sf is the maximum common scaling factor for the task in 5. 
In our example, S = T, therefore the second term in the above equation is 
zero. The new utilization is now given by 1.7941 x 0.4619 = 0.8287. This 
achievable improvement in utilization is promising for the application with re- 
gards to, scalability, execution time estimation, portability and fault-tolerance 
as described in chapter 3. 

9.2 Schedulability of Task-Sets with Arrivals 

As described in chapter 4, solving the problem of scalability in end-to-end real- 
time systems involves solving the two problems of (i) schedulability of tasks 
on a single component without ignoring arrival times and, (ii) scalability of 
tasks with non-zero arrival times. The first of these problems was discussed in 
chapter 6. 

This section discusses this result by applying it the AOCS case-study. 
Our first example involves, treating the AOCS as an end-to-end task system 
with each task comprising only one sub-task which runs on the only component 
in the system, i.e., the processor. Now, the determining the schedulability of 
the tasks involves computing their worst-case response times. For comparison 
purposes, the following table (9.2) gives the worst-case response times using 
two different mechanisms, i,e., the critical instant approach {W C c ) and. the 
approach described in chapter 6 ( WC T ). The third column gives the percentage 
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improvement in the response time obtained by using our precise approach as 
opposed to the critical instant approach. The fourth column gives the slack 
savings achieved by using our approach. Slack savings (in percentage) is given 
by the formula: 


SSi = 


W C[ - wc\ 


x 100 


While the percentage improvement obtained does have some merit in 
explaining the need for a more precise approach, the slack savings parameter 
qualifies the ability of a task to accommodate task interdependence (e.g., prece- 
dence), withstand temporary overloads, accommodate aperiodics in the system 
and restrict jitter in end-to-end systems. 


Table 9.2: Response times of Tasks 


Task Name 

Resp Time 

% Improvement 

Slack Savings (in %) 


wc c 

WC T 



BUS-INTERRUPT 

0.18 

0.18 

0.0 

0.0 

REAL-TIME-CLOCK 

0.46 

0.46 

0.0 

0.0 

READ-BUSJP 

2.22 

2.22 

0.0 

0.0 

COMMAND-ACUTUATORS 

4,35 

4.35 

0.0 

0.0 

REQUEST-DSS-DATA 

5.78 

3.65 

36.85 

13.60 

REQUEST -WHEEL-SPEEDS 

7.21 

3.65 

49.37 

17.30 

REQUEST JRES-DATA 

8.64 

5.08 

41.20 

15.77 

TELEMETRY-RESPONSE 

13.59 

8.27 

39.14 

19.84 

PROCESS-IRES-DATA 

23.56 

14.32 

39.21 

22.11 

READ- YAW-GYRO 

27.64 

14.11 

48.95 

13.06 

CO NT RO LX AW 

56.22 

42.44 

24.51 

7.77 

PROCESS-DSS-DATA 

63.14 

15.19 

75.94 

12.14 

CA LIB RATE-GYRO 

71.81 

23.86 

66.77 

5.36 

TELECOMMANDS 

74.31 

16.61 

77.64 

31.27 


As a second demonstration of the results in Chapter 6, we consider an 
actual decomposition of the task-set into sub-tasks. The chosen decomposition 




is only one of the possible decompositions obtained by arbitrarily dividing and 
assigning tasks to four components. The decomposed task-set is given in Figure 
9.3. 


Table 9.3: Decomposition of tasks 


Task Name 

Resource(s) 

BUS-INTERRUPT 

R i 

REAL-TIME-CLOCK 

R* 

READ-BUS-IP 

#3 

COMMANDjVCUTUATORS 

R\ — ► R+ 

REQUEST-DSS-DATA 

R\ — ► R2 

REQUEST-WHEEL-SPEEDS 

R\ — * 

REQ U EST-I RES-D ATA 

R 4 

TELEMETRY-RESPONSE 

R 4 

PROCESS-IRES-DATA 

R\ — ► R2 — ► /?3 

READ-YAW .GYRO 

R\ — ► R$ 

CONTROL-LAW 

R\ — ► R2 — ► R4 

PROCESS.DSS.DATA 

R\ — ► R3 

CALIBRATE.GYRO 

R 2 — ^ ► Ra 

TELECOMMANDS 

R\ — ► R% 


The following tables (9.4, 9.5, 9.6, 9.7) give details of the analysis of 
each component in turn. The parameter of the sub-tasks that run on the first 
component R x , are directly inherited from the parent. Further, the deadline 
parameter is not required in this problem since we are only interested in finding 
the worst-case response times of tasks, which are given by the sum of the 
response times of their individual sub-tasks. The arrival time parameter of 
sub-tasks on component R 3 (and subsequently R 3 and R+) are obtained by the 
phase adjustment mechanism. 

The following table (9.8) compares the resulting worst-case response 
times of tasks with their deadlines. Clearly, all tasks meet their deadlines. 



121 


Table 9.4: Analysis of Component R i 


Task Name 

Priority 

Period 

Arrival 

Exec 

Response Time 

BUS-INTERRUPT 

62 

50 

0.00 

0.18 

0.18 

COMMAND.ACUTUATORS 

20 

200 

50.00 

1.13 

1.31 

REQUEST-DSS.DATA 

19 

200 

150.00 

0.43 

0.61 

REQUEST-WHEEL-SPEEDS 

18 

200 

0.00 

0.70 

1.88 

PROCESS-IRES.DATA 

14 

100 

50.00 

3.21 

4.52 

RE AD- YAW .GYRO 

12 

500 

0.00 

1.08 

2.96 

CONTROL-LAW 

8 

200 

50.00 

5.00 

9.52 

PROCESS-DSS.DATA 

6 

1000 

200.00 

2.10 

3.98 

TELECOMMANDS 

4 

500 

0.00 

1.00 

3.96 


Table 9.5: Analysis of Component R? 


Task Name 

Priority 

Period 

Arrival 

Exec 

Resp Time 

REAL-TIME-CLOCK 

27 

50 

0.00 

0.28 

0.28 

REQUEST-DSS.DATA 

19 

200 

150.61 

1.00 

1.00 

PROCESSJRES-DATA 

14 

100 

54.82 

3.00 

3.00 

CONTROL-LAW 

8 

200 

59.52 

5.00 

5.00 

CALIBRATE-GYRO 

5 

1000 

200.00 

3.0 

3.28 

TELECOMMANDS 

4 

500 

3.96 

1.50 

1.50 


Further, by comparing these response times against those in table 9.2 we ob- 
serve the enormous improvement in response times of tasks. 


9.3 Scalability in End-to-End Systems 

As mentioned in the previous section, the second issue to be addressed in solving 
the scalability problem in end-to-end systems is: scalability of tasks on a single 
component with non-zero arrival times. This was the subject of Chapter i . In 
this section, we first compare the scaling factor obtained by incorporating task 
arrival times against, that obtained by using the critical instant assumption 
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Table 9.6: Analysis of Component R 3 


Task Name 

Priority 

Period 

Arrival 

Exec 

Resp Time 

READ-BUSJP 

23 

10 

0.00 

1.76 

1.76 

REQUEST -WHEEL-SPEEDS 

18 

200 

1.88 

0.73 

0.73 

PROCESS-IRES.DATA 

14 

100 

57.82 

2.00 

2.00 

READ-YAW.GYRO 

12 

500 

2.96 

3.00 

3.00 

PROCESS.DSS.DATA 

6 

1000 

203.98 

3.06 

3.06 

Table 9.7: 

Analysis of Component R 4 


Task Name 

Priority 

Period 

Arrival 

Exec 

Resp Time 

COMMAND-ACUTUATORS 

20 

200 

51.31 

1.0 

1.0 

REQUESTJRES-DATA 

17 

100 

0.00 

1.43 

1.43 

TELEMETRY-RESPONSE 

15 

200 

0.00 

3.19 

4.62 

CONTROL-LAW 

8 

200 

64.52 

7.84 

7.84 

CALIBRATE-GYRO 

5 

1000 

203.28 

3.91 

4.68 


(chapter 5). Table 9.9 gives the summary of this comparison. The maximum 
common scaling factor by the precise approach is under the second column 
(sf (actual)) and that obtained by the critical instant assumption in chapter 5 
is under the third column (sf(orig)). The task-set is assumed to run on a 
single component and accordingly each task has a single sub-task. The subset 
S that has to be scaled is same as T. The common scaling factor s f (actual) is 
2.1295 which is clearly greater than 1.7941 obtained by the other mechanism. In 
terms of utilization the resultant task-set utilization is 0.9836 or 98.36%. Note 
that, ideally one would expect to be able to obtain 100% utilization on scaling, 
however, this is not achievable in the case of static fixed priority schedulers. 

Recall that in chapter 4 problem of scalability of task-sets in end-to-end 
real-times systems comes in two different forms: task changes and component 
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Table 9.8: Schedulability of the End-to-End Tasks 


Task Name 

Response Time Deadline 

BUSJNTERRUPT 

0.18 

1.00 

REAL-TIME-CLOCK 

0.28 

9.00 

READ-BUSJP 

1.76 

10.00 

COMMAND-ACUTUATORS 

2.31 

14.00 

REQUEST.DSS.DATA 

1.61 

17.00 

REQUEST-WHEEL-SPEEDS 

2.61 

22.00 

REQ U EST.I RES .DATA 

1.43 

24.00 

TELEMETRY-RESPONSE 

4.62 

30.00 

P ROC ESS-I RES-D ATA 

9.52 

50.00 

READ_YAW -GYRO 

5.96 

100.00 

CONTROL -LAW 

22.36 

200.00 

PROCESS-DSS-DATA 

7.04 

400.00 

CALIB RATE-GYRO 

9.68 

900.00 

TELECOMMANDS 

5.46 

187.00 


changes. The following modification of the case study demonstrates how our 
approach to finding the precise scaling factor can be applied in an end-to-end 
scenario where component changes can occur. The same decomposition used 
in the previous is used here. The following tables (9.10, 9.11, 9.12 and 9.13) 
give the details of the scaling factor computation for each of the components. 
The deadline parameter for each sub-task is obtained by using a heuristic that 
divides the slack of a task among its sub-tasks in a weighted proportion of their 
execution times. Now, For example, if the set of components that undergo 
change are {R^yfU} then the scaling factor is min {5.3949, 6.4935} which is 


5.3949. 
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Table 9.9: Task Table with Scaling Factors 


Task Name 

Scaling Factor 
sf (actual) sf(orig) 

BUSJNTERRUPT 

5.5556 

5.5556 

REAL-TIME-CLOCK 

19.5652 

19.5652 

READ.BUSJP 

4.5045 

4.5045 

COMMAND.ACUTUATORS 

2.2989 

2.2988 

REQUEST.DSS.DATA 

3.1423 

2.2546 

REQUEST -WHEEL-SPEEDS 

3.6969 

2.2296 

REQ U EST J RES-DATA 

2.9240 

1.9736 

TELEMETRY-RESPONSE 

2.5445 

1.9543 

PROCESS.IRES.DATA 

2.5510 

1.8463 

READ-YAW .GYRO 

2.5786 

2.4740 

CONTROL-LAW 

2.1877 

2.1877 

PROCESS-DSS-DATA 

2.2119 

2.1748 

CALIBRATE-GYRO 

2.1885 

2.1645 

TELECOMMANDS 

2.1295 

1.7941 

C ommon Sea ling Factor 

2.1295 

1.7941 


Table 9.10: Scaling on Component R\ 


Task Name 

Priority Period 

Arrival 

Exec 

Deadline 

SF 

BUSJNTERRUPT 

62 

50 

0.00 

0.18 

1.00 

5.5556 

COMMAND-ACUTUATORS 

20 

200 

50.00 

1.13 

7.43 

5.6696 

REQ U EST-DSS-D ATA 

19 

200 

150.00 

0.43 

5.11 

8.3800 

REQUEST-WHEEL-SPEEDS 

18 

200 

0.00 

0.70 

10.77 

5.7283 

PROCESSJRESJ)ATA 

14 

100 

50.00 

3.21 

19.55 

4.3251 

READ-YAW-GYRO 

12 

500 

0.00 

1.08 

26.47 

8.9427 

CONTROLS AW 

8 

200 

50.00 

5.00 

43.78 

4.5990 

PROCESS-DSS-DATA 

6 

1000 

200.00 

2.10 

162.79 

11.4286 

TELECOMMANDS 

4 

500 

0.00 

1.00 

74.80 

8.4890 

Common Scaling Factor 



= 

4.3251 





Table 9.11: Scaling on Component R 2 


Task Name 

Priority 

Period 

Arrival 

Exec 

Deadline 

SF 

REAL-TIME-CLOCK 

27 

50 

0.00 

0.28 

9.00 

32.1429 

REQUEST.DSS.DATA 

19 

200 

150.61 

1.00 

11.89 

9.7641 

PROCESS JRES.DATA 

14 

100 

54.82 

3.00 

18.27 

5.3949 

CONTROL -LAW 

8 

200 

59.52 

5.00 

43.78 

5.8554 

CA LIB RATE-GYRO 

5 

1000 

200.00 

3.0 

390.73 

13.6799 

TELECOMMANDS 

4 

500 

3.96 

1.50 

112.20 

11.2510 

Common Scaling Factor 



= 

5.3949 


Table 9.12: Scaling on Component R 3 


Task Name 

Priority 

Period 

Arrival 

Exec 

Deadline 

SF 

READ-BUS-IP 

23 

10 

0.00 

1.76 

10.00 

5.6818 

REQUEST-WHEEL-SPEEDS 

18 

200 

1.88 

0.73 

11.23 

4.0161 

PROCESS-IRES-DATA 

14 

100 

57.82 

2.00 

12.18 

3.2394 

READ-YAW-GYRO 

12 

500 

2.96 

3.00 

73.53 

4.0462 

PROCESS-DSS-DATA 

6 

1000 

203.98 

3.06 

237.21 

4.6894 

Common Scaling Factor 



= 

3.2394 


Table 9.13: Scaling on Component R+ 


Task Name 

Priority 

Period 

Arrival 

Exec 

Deadline 

SF 

COMMAND-ACUTUATORS 

20 

200 

51.31 

1.0 

6.57 

6.5727 

REQUEST JRES-DATA 

17 

100 

0.00 

1.43 

24.00 

16.7832 

TELEMETRY -RESPONSE 

15 

200 

0.00 

3.19 

30.00 

6.4935 

CONTROL-LAW 

8 

200 

64.52 

7.84 

112.43 

9.0236 

CALIBRATE.GYRO 

5 

1000 

203.28 

3.91 

509.26 

12.3508 

Common Scaling Factor 



= 

6.4935 






Chapter 10 


Conclusions 


The significant contributions of this thesis can be broadly summarized as fol- 
lows: 

• We have addressed the need to handle complexity in real-time systems in 
all phases of system design, viz., design, development and maintenance. 

• We have presented a novel perspective to analyzing real-time systems that 
in addition to ascertaining the ability of a system to meet task deadlines 
also qualifies these guarantees. 

• The need to qualify guarantees was shown to arise from the following 
scenarios pertinent in the design, development and maintenance of real 
time systems: 

- Scaling application requirements : As a system evolves the function- 
alities of tasks expand, reflecting in terms of increase in code size 
and/or improvement in data handling of tasks. This increase af- 
fects the schedulability guarantees made using the previous execu- 
tion times. Therefore, what we are interested in is, finding a factor 
by which the execution times can be scaled (capturing the data han- 
dling change) without invalidating the schedulability guarantees. 
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- Task execution time estimation: Using mean task execution times 
as opposed to worst-case execution times in schedulability analysis 
reduces the pessimism (leading to over design and under-utilization 
of resources) inherent in the computation. Unfortunately however, 
using the mean could lead to cases where the guarantees provided 
by the schedulability analysis could be invalid (The number of such 
cases being determined directly by the variance in the computed 
mean execution time). Therefore, it is necessary to accommodate 
the variance information along with the mean (for task execution 
times). 

- Porting applications: Any analysis performed (to guarantee perfor- 
mance) assuming particular values of task execution times becomes 
invalid once the target platform changes. For example, a faster pro- 
cessor could result in a lower execution time (not invalidating the 
analysis), but a slower processor would surely have an adverse af- 
fect on the schedulability analysis. As a system evolves, though 
in general the overall system is likely to improve, the performance 
of individual components (some processors for example) might not 
always improve. Another instance where a target platform is in gen- 
eral slower, arises in the case of prototype building and testing [51]. 

- Fault Tolerance: It is common practice to provide fault-tolerant op- 
eration by the use of redundant components (often at least one sec- 
ondary component). In general, secondary components provide only 
a minimal functionality (sufficient to keep the system operational till 
the primary is fixed) and therefore tend to be slower. Any schedu- 



lability analysis guarantees provided with the primary component 
as the target will be invalid once the system falls back onto the 
secondary. 

• The scaling factor problem (refer to Chapter 4) defines a quantitative 
measure that in essence captures the above mentioned scenarios under a 
uniform framework. The problem is generic in the sense that it leaves 
such particulars as: 

- the scheduling mechanism, 

- deadline to period relationship, and, 

- arrival information, 

open. For example an instance of the problem could be to find the scal- 
ing factor when the assumed scheduling mechanism is a static fixed rate 
monotonic priority assignment, the task deadlines are less than or equal 
to their periods, and, the task arrivals are arbitrary. 

• The scaling factor problem was first formulated in the context of uni- 
processor real-time systems. This scenario can be more generally re- 
ferred to as the single component scenario. The tasks running on the 
single component in question are evaluated with regards to their abil- 
ity to meet their requirements (processing and deadline). Further, we 
compute a measure that gives us the ability of these tasks to scale-up 
without violating their guarantees. One important assumption made in 
this context was that the arrival times of the various tasks can be as- 
sumed to be zero. This assumption has helped us in using the critical 
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instant argument to ascertain task schedulability and also in finding the 
scaling factor. We demonstrated some justifications for the use of this 
argument, particularly in the context of single component systems with 
independent tasks. 

• Unlike uniprocessor systems, in end-to-end systems, the scaling factor 
problem appears in two different scenarios, viz., component changes and 
task changes. We showed how both these scenarios arise and how they 
can be reduced to solving the following fundamental problems: 

- Compute sub-task parameters of periodicity and deadline. 

- Given a task-set T of n tasks (with non-zero arrivals) executing on a 
single component, find the worst-case completion times of all tasks 
in the task-set. 

- Solve the scaling problem when the tasks have arbitrary non-zero 
arrivals. 

The first of the above problems involved finding sub-task periodicities 
by a technique called phase adjustment and sub-task deadlines by using 
a heuristic based on proportional division of the total slack of a task 
among its sub-tasks. Our solution to the second problem is the subject 
of Chapter 6. This problem has been observed to be relevant in many 
other contexts in real-time systems, and a discussion to this end can be 
found in the same Chapter. Chapter 7 presents a solution to the third 
problem listed above. The complexity is introduced mainly by having to 
accommodate task arrivals into the analysis. However, this consideration 
adds validity to our work and also bridges the gap between theory and 



practice by better modeling the behavior of current complex real-time 
systems. 

• Finally we presented an application of the scaling factor problem in the 
context of real-time communication. The problem considered is the ad- 
mission- control of real-time channels (Ferrari et. al. [9]). Admission 
control is the mechanism by which multiple real-time connections can si- 
multaneously share the resources of a packet switching network without 
resulting in congestion. The mechanism used to determine the admissi- 
bility of a real-time channel involves verifying at each intermediate link 
(along the path) in turn whether the RT channel’s QoS requirements can 
be guaranteed. If a channel’s requirements can be met at each of the 
intermediate links then we can accept the channel. If however, the chan- 
nel’s requirements cannot be met at any of the intermediate link then we 
can reject the channel. In fact the first such link that deems the chan- 
nel inadmissible is sufficient to confirm that the channel would not be 
admissible. 

This problem is shown to be analogous to the end-to-end schedulability 
problem with the exception that the solution cannot be based on evalu- 
ating a channels admissibility by doing a complete (expensive) schedula- 
bility test. To this end, we proposed a heuristic approach that is based 
on the scaling factor computation. The room for accommodating a new 
channel into a system is expressed in terms of the maximum scaling fac- 
tor with which the requirements of the channels already in the system 
can be scaled without violating their guarantees. This expression is then 
compared against the requirements of the new channel that is to be con- 
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sidered for admission. The expression being of a heuristic nature, we 
resorted to a simulation study (details in Chapter 8), the results of which 
have demonstrated the effectiveness of our approach. 
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Figure A. 3: n = 12 and k = 0.5 
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Figure A. 4: n = 16 and k = 0.5 
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Figure A. 5: n = 4 and k = 0.6 



Figure A. 6: n = 8 and /c = 0.6 












0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1 


Figure A. 8: n — 12 and k = 0.6 









Figure A. 9: n = 4 and k = 0.7 



Figure A. 10: n — 8 and k = 0.7 


















Figure A. 13: n = 4 and k = 0.8 



Figure A. 14: n = 8 and k = 0.8 











Figure A. 16: n = 16 and k = 0.8 









Figure A. 17: n = 4 and k = 0.9 



Figure A. 18: n — 8 and /c = 0.9 
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Figure A. 23: n = 12 and k = 1.0 



Figure A. 24: n = 16 and k = 1.0 
















Appendix B 


The Olympus Attitude and Orbital Control 

System 


The first two tables list the periodic tasks in the system and the last table lists 
the sporadic tasks. The parameter of periodicity of sporadic tasks is a derived 
parameter chosen for our study and not specified in the original study. The 
first parameter, critical level, is not used in our study, but essentially adds to 
the priority information of tasks. In general we could have had HARD, SOFT 
or FIRM categories of criticality and a special category called INTERRUPT, 
that implies that the corresponding task should be executed non-preemptively. 
In this case study there is only one task that is not categorized as HARD. Since 
this task (BUS JNTERRUPT) is assigned the highest priority, it is guaranteed 
to run un-preempted, satisfying the requirement of tasks that are categorized 
as INTERRRUPT. 

The periodicity of sporadic tasks was chosen randomly to lie between 
the minimum inter- arrival and the average periodicity of periodic tasks. The 
minimum inter-arrival time parameter of sporadic tasks gives a lower bound on 
successive arrivals and is very rarely encountered in practice. Therefore, even if 
two successive arrivals of a sporadic task do occur at this minimum interval the 
probability of the next instance also occurring at this interval is very remote. 
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Table B.l: Periodic Tasks 


Task Name 

Characteristic Value 

REAL-TIME-CLOCK 

Critical Level HARD 

Priority 27 

Period 50.00 

Arrival Time 0.00 

Execution Time 0.28 

Deadline 9.00 

READJ3USJP 

Critical Level HARD 

Priority 23 

Period 10.00 

Arrival Time 0.00 

Execution Time 1.76 

Deadline 10.00 

COMMAND.ACUTUATORS 

Critical Level HARD 

Priority 20 

Period 200.00 

Arrival Time 50.00 

Execution Time 2.13 

Deadline 14.00 

REQUEST-DSS-DATA 

Critical Level HARD 

Priority 19 

Period 200.00 

Arrival Time 150.00 

Execution Time 1.43 
Deadline 17.00 

REQUEST-WHEEL-SPEEDS 

Critical Level HARD 

Priority 18 

Period 200 

Arrival Time 0.00 

Execution Time 1.43 

Deadline 22.00 




Table B.2: Periodic Tasks - continued 


Task Name 

Characteristic Value 

REQUEST-IRES .DATA 

Critical Level HARD 

Priority 17 

Period 100.00 

Arrival Time 0.00 

Execution Time 1.43 
Deadline 24.00 

P RO C ESS -I RES -DATA 

Critical Level HARD 

Priority 14 

Period 100.00 

Arrival Time 50.00 

Execution Time 8.21 
Deadline 50.0 

CONTROL-LAW 

Critical Level HARD 

Priority 8 

Period 200.00 

Arrival Time 50.00 

Execution Time 22.84 

Deadline 200.00 

PROCESS-DSS-DATA 

Critical Level HARD 

Priority 6 

Period 1000.00 

Arrival Time 200.00 

Execution Time 5.16 

Deadline 400.00 

CALIBRATE.GYRO 

Critical Level HARD 

Priority 5 

Period 1000.00 

Arrival Time 200.00 

Execution Time 6.91 

Deadline 900.00 




Table B.3: Sporadic Tasks 


Task Name 

Characteristic 

Value 

BUS-INTERRUPT 

Critical Level 

INTERRUPT 


Priority 

62 


Min Inter-arrival 

10.00 


Period 

50.00 


Arrival Time 

0.0 


Execution Time 

0.18 


Deadline 

0.63 

TELEMETRY-RESPONSE 

Critical Level 

HARD 


Priority 

15 


Min Inter-arrival 

100.00 


Period 

200 


Arrival Time 

0.00 


Execution Time 

3.19 


Deadline 

30.00 

READ-YAW-GYRO 

Critical Level 

HARD 


Priority 

12 


Min Inter-arrival 

100.00 


Period 

500.00 


Arrival Time 

0.00 


Execution Time 

4.08 


Deadline 

100.0 

TELECOMMANDS 

Critical Level 

HARD 


Priority 

4 


Min Inter-arrival 

200.00 


Period 

500.00 


Arrival Time 

0.00 


Execution Time 

2.50 


Deadline 

200.00 




